# T2TRG / W3C WoT meeting in Singapore Github: https://github.com/t2trg/2019-11-singapore Webex: https://is.gd/t2trg201911webex Remote attendees: * Michael Richardson (part time) * Jim Schaad * Kazuyuki Ashimura (Kaz) * Michael Koster * Petri Laari * Ryuichi Matsukara * Taki Kamiya (afternoon) * Sebastian Kaebisch * Ege Korkan (afternoon) * Daniel Peintner (afternoon) ## Welcome, Logistics IRTF IPR applies. W3C IPR applies. Carsten opened the meeting with intro to IRTF & T2TRG. ## Introduction to role of semantics for IoT (Carsten Bormann) In IoT we will scale up number of nodes but also scale down the capabilities of a node and time we can put into configuring a single node. Devices may look very unmanaged. Software updates are difficult and more stakeholders. In IRTF "Thing" is a device with physical presence (physical object). Some form of digital interface connected to the Internet. "If can have API call to create another, it's not a Thing". Typically not considering network equipment since they are there only to do something in the digital side. But some overlap. Need thing to describe itself. Need form of self-description. To provide information to operate without manual and intelligent guessing. Juan-Carlos Zuniga: is possible to do via proxy? Or does the cattle have to answer? Carsten: even for cows self-description useful. But may be links to other resources. McCool: will talk about this in discovery. Self-discoverable devices. Milan: important to distinguish runtime discovery as opposed to design-time. Assumption: if discovering something from the range of things I know about or something I see first time and would have to tell me how to interact with. Intrinsic vs extrinsic: info about device vs info about the role and context. Configuration somewhere in between. Marie-Jose M: difference between two; want to say what is the usage. So that intrinsic can be interpreted the right way. Not totally independent. Carsten: Often talking about class information, even if talk about things like objects. Using hypermedia concept too. Web of Things concept: using hypermedia to describe IoT devices too. Resources, links, forms -- client navigating what is out there. Client not programmed to exact properties it finds but has flexibility. Early form of resource discovery in RFC6690 based on web linking. But what do the "if" and "rt" values mean? Can't describe the universe here but need to point to something that has been defined. Eliot Lear: good example; if look at the way different SDOs define Temperature, one SDO in Celsius, other in Kelvin, but if pull value from device, need to at least validate if it's Kelvin or Celsius. Carsten: yes, to be discussed in a bit Need reusable, machine readable formats and reusable definitions. It's complicated; how about layered structure? One structure: semantic, structural, syntactic interop. For each layer might want to have models. Machine readable self-description. We have models, metamodels, meta-metamodels, etc. Often need to read a manual (for people), but we want machine-readable. Often used word is "schema"; prefer to call models. Another version of 3 layers: info model, data model, serialization. Data models getting a lot of the attention at the moment; very important of the three. Have frameworks for each. RDF a generic data model with set of triples. Powerful concept developed independent of the serialization format. Currently fashionable to use JSON-LD serialization. We might want to use tools from RDF. Also interaction models; have protocols. Interaction patterns, e.g., properties/actions/events. Kaz: mentioned W3C policy in the webex. (15 min break) ## Keynote: W3C Web of Things (WoT) Status and Roadmap (Michael McCool) W3C WoT in the middle of rechartering now; requirement gathering and use cases. Good time for input. In the end set of discussion items; looking for input. Two groups: Interest and Working group, similarities to IRTF/IETF split, but lots of overlap. Standard development in the WG. Eliot: IETF has a bit different kind of symmetry. To be discussed in IETF next week. If should have "IoT Dispatch" style group. Two major deliverables published: architecture and Thing Description. Scripting API was originally normative but is holding off now to wait clarifications on the deployment model. But have open source implementations already. Eliot: would content that devices that listen are security threat to rest of the network. If can't turn communication around, have to listen. Good to see WoT protocol binding where the device is going to connect to controller, rather than the other way around, seems far better. Want to avoid client/server terminology. Use producer/consumer on who is making/reading the TD. Certain things in TD, like eventing, where device initiates communication. But lots of server initiated. TD can be used to describe anything, profiles can be used to describe what's good. Eliot: worth capturing; where protocol binding sits with H/3 etc. Also relation with SDF / OneDM. Also for data modeling like JSON schema, YANG. Also need alignment on the terms used. You could also use TD in hypermedia way where you get new TD for each interaction. Also "Thing being physical device", can see many uses where Thing could be "AI system running in cloud" that could be described with TD. Important aspect: URI schemes. For example MQTT didn't have it. Not doing only RESTful here. Req/response and pub/sub style patterns here. Also talking with Intel folks using ZeroMQ. Have abstraction for affordances. Tells you what you can do and semantics gives you more details. Protocol binding tells you how to do that. TD is serialized JSON-LD file. There are people who are allergic to RDF, but good thing about JSON-LD 1.1 is that it looks like idiomatic JSON. But if want to put this in RDF data base, can do it. @context enables to pull in external vocabularies. Can have namespace and terms from that namespace. Eliot: information is schema definition? set of properties that are relatively static. State information here? To be addressed later. Also is it class or instance definition. Intent is instance definition. Clear that lot of the stuff is same for many -- hence class. The id may change for example. Have Thing Template for static info. But if have interaction dependent on state; could modify TD to make that available, could return a new TD as part of interaction. Eliot: low end devices; chances of them offering this directly is slim. Is way to discover this info so that device doesn't have to ship this? Yes. Several use cases how could be delivered. Defining now requirements for the discovery (e.g., security). But will not be just one way. Eliot: have some ideas, as long as have appropriate interaction mechanisms, and portions of schema, you're off to good running start. Have link section for defining more meaningful relations. Security work ongoing Milan: IIC document on security; how related? Have done much more on threat modeling. Also need to align with other orgs like NIST that has been given mandate to set requirements US gov can buy. Constantly reviewing that. Don't want to duplicate things but overlap now. Interesting discussion wrt edge computing too. Current status: using JSON-LD 1.1. JSON-LD 1.0 was for RDF storage. 1.1 is different: how we can add semantic data to existing JSON. LD 1.1 still a draft. But wanted to support web developers who use idiomatic JSON. Extension points defined that might be rolled into the standard later. Basic security now. But ACE for example for future work. Eliot: should application ID be bound to network ID needs work New group in W3C for distributed IDs. Some want immutable IDs, but privacy issues. We made IDs optional -- if want ad-hoc communication. Have lots of discussion on this ID point. JC: discussion we had for long time in IEEE and IETF. Argument the same: can track user with fingerprint but globally unique ID makes it more easy. Having it optional doesn't solve since people who don't understand this will use it. Right way to handle this is to distribute TDs. How to treat entire TD as personal information. Eliot: opposite side, if large org manager, need to know what's in your network. Know it has not been tampered with. Matter of confidence, not binary. Have IEEE spec ".ar". There is stage where IoT is particularly important. How the device gets to network the first place. Think there's a step where you have to reveal a bit. Don't have lifecycle yet, really need to have that. Also tampering TDs; need to create checksums and enable checking. Matthias: W3C blocks anything that has privacy issues. In industrial systems no persons involved. Need to think what mechanisms needed for bootstrap etc. How to keep transparent for global management. Eliot: often need localized IDs. With Fairhair noticed that when have small amount of apps like light control. Want to keep amount of code low. Includes ID mechanism. If able to bind app ID to network ID, unlike with generic purpose computer, how can capitalize on the binding Good questions but don't have to solve here yet. MJ: some were addressed in CCN/ICN world. Discovery for example, and pub/sub. Planning to reuse some of that? Many different ways to do discovery. Different contexts, local, global, constrained devices, etc. Need to understand the requirements and see what we can use. Also CoRE RD stuff. Just had meeting with GoDaddy who want do DNS discovery. Could use QR codes. Want to modularize this. Have some ideas how to do this relatively clean. Kaz: work in decentralized IDs at W3C. Should think about how to deal with ID management. Great starting point here to start collaboration work across ecosystems. Theme of the WS semantics. How the work done for TD relates? Two large camps: RDF users and others. We don't force RDF but should be possible to use it. Want to connect OneDM SDF to RDF. SDF model is very similar to iotschema. Should be able to get into RDF easily. Can think of RDF as the assembly language of semantics. Milan: do people hate RDF because it's hard to use or because not proven useful? Tackling a difficult problem. Some complexity from there. When people have done their own way, end up with similar level of complexity. Learning curve thing. Good about SDF that starts at lower level but enables to have the tools. Another reason for RDF issues: semantic web was suppose to use for annotating web pages. Failed there. But in IoT less human-readable stuff. But larger context. Have now tech that is quite mature, fits IoT problem better than the original semantic web model. For discovery don't necessarily want to give SPARQL interface but keyword based discovery, for example. Eliot: who is allergic to RDF? All about tooling. Devs don't want to learn SDF either. Everyone wants to minimize their work. Good examples, tools, and community helps. But hard to project. But technical objectives, like inferring, works. What's happening in SDF is that people are defining their things with SDF already. Lots of momentum for it and worth investigating. Issue with RDF was also very elaborate ontologies that are hard to use. iotschema doing simple ones now. Milan: all academic work have problem of tabula rasa. Need to learn everything from the RDF. Hard even for simple things like temperature. Matthias: good question where RDF allergy comes from. Seems the term is burnt. Got lots of comments that "don't put RDF to charter". But doesn't make sense to re-invent. For TD text needed to always hide it because we knew the benefits. Hard to come up with something that bridges the two worlds. We need the tooling to make this working. ... Profiles can define a finite set that needs to be included, and things like max length for strings, needed protocol bindings. Defining a subset of TDs that are implementable and identify profile. Argument for more than one profile is home/industrial space with different requirements. Also want to support best practices. JC: best practices work happening in W3C? For example, some people want to make descriptions mandatory, but personally want to avoid for privacy issues. Stuff should just work when plugged in. Eliot: should not be the only goal Milan: all authenticated entities should be able to do discovery Even queries should not be allowed for random endpoints. "First contact protocol" tells where's the directory service. Then authenticate for it and then only can do queries. Eliot: exactly problem Fairhair hit; and similar solution direction they took. Should not broadcast TD publicly. Can be many mechanisms for introduction. Directory service can be plain old web service and use things like OAuth; can use existing tech. Directory has access control; could be public then. MJ: hierarchy of directories? Thinking of autonomous systems that need to work even without connection. Would not necessarily be "big web service". JC: how about constrained devices exposing? TDs not often exposed by devices. IPSO does that though so that works too when lightweight. Various things to look at IETF. Onboarding, discovery, hypermedia stuff. To be continued from slide 20... ## OneDM intro and goals, approach (Michael Koster) Set of organizations working on common models. But first need a language to describe those. Coming from Zigbee hive meeting late 2018. identified need for application layer standard here. Started by creating a common language. Now collecting a set of representative models to do pressure testing. Not necessarily device models but models of interaction. Idea to publish the models. Setting up playground area for comparing patterns and informal down selection. Outcome pretty good. All agreed to publish data models under BSD 3-clause. Lots of work done on OMA model translation. Ari will talk later. Have good models from Zigbee dot-dot and OCF appliances. OCF talking about using SDF instead of Swagger. Semantic model includes behavior and affordances. Start with affordance and then can integrate behaviour modeling. Should be able to do reasoning on these instead of person having to program his house. Now have events,actions, properties. Also data types for constraints and semantics for reusable parts. Also high level concepts like objects that group things together. Semantic interop focuses on object level. Even thermostat could be composed from multiple objects. Idea is to break up things in modular fashion. Also idea of views to virtualize affordances. Aligning with some modeling done in OCF and other orgs. odmProperty for thing states, for example operational model of thermostat. odmAction affordance that usually impacts physical world. Emulates function calls with parameters. May not always work: closing gate could not succeed. More complex things with return status. odmEvents less defined, state changes sent as notifications. Tendency to call notifications. Some questions could be left to protocol binging; how events obtained. Could have time stamps etc. Not lots of examples of people using events so not as well defined. odmType just data type. Application could identify measurement and setpoint temperature with some constraints. Sometimes constraints nailed down in model sometimes in runtime. odmObjects collections of the above. Need to strike a balance how much functionality. Learning about the trade-offs but lots of good examples too. Like Zigbee cluster library. Pretty good notion what those trade-offs are. About how you manage evolution of these things. Related to versioning (topic later today). odmThing high level things like light bulb; with info like manufacturer, maybe MUD, and enable finding things semantically. Also construct "product" that is just a thing with extra info like serial number. odmView for virtualizing things.. ... SDF language overview: domain specific language using JSON. Associates semantic terms with type definitions. Info block for license and copyright information. Namespaces for having multiple uses. Ultimately want one OneDM namespace but also basic tools to use to manage ecosystem models. Namespaces just URI prefixes. Also default namespace. Easy to make RDF graph out of this and convert to iotschema format or ad-hoc formats, or use in Thing Descriptions. Idea to make easy for developers to use. Borrowing JSON schema style. Definition defines a term and constraints (qualities). Declaration is use of a term. SDF references used to modularize things. Define in one place and provide pointer to it. Started with relative pointers but we might be able to get by with just RFC6901 style. Processing model for using references and resolving things. Each name space has SDF files that are processed. Compiling all files together to look like one big file. To avoid name collisions use name spaces. Defaultnamespace gives the name space where terms in that file go to. Want to provide semantic metadata to concepts to enable reasoning. Using existing ontologies. Also use JSON pointer for defining what is required in object. High level composition with odmThing and view. Next steps: doing updates to language. Agreed on syntax and will start building models and evaluating. Want to demonstrate what this is good for: building models that are semantically compatible. Working on GW for automated translation to show that. Still discussing timig of going fully public. Also Semantic Proxy W3C WoT integration. McCool: need to talk about relations ship of TD vs SDF files. SDF files seem to be class definitions. Also overlap with TDs data schemas. Can talk of overlap and relation? Made presentation for iotschema teleconf in July that describes this. We're building fundamental models that provide "@type" definitions. These are ways for people to supply devices, and domain experts describing what devices do, to create high level models. Thing description doesn't have things and objects, just events,actions, properties. Need to figure out where the annotations go. This provides semantic annotation and set of affordances to build TDs out of. With models that are agreed across orgs. Will have lots of models specific to vertical domains. Hoping to git the right level, whether building TD for smart home or industrial system. Can pick a set of models appropriate and attach a protocol binging for automating things. We're putting together packages; temperature sensor for smart home. There are people who want to build protocol bindings that look like TDs. We should first demo doing TDs for protocol binding. Ari: could take as hackathon topic? McCool: was planning to look at compiler. Need to resolve the roles of each. Useful things in SDF that could be in TDs like object model. Need alignment before things get more confusing. Nice to use TDs for protocol binding. And bring TDs aligned with SDF. Milan: for pragmatic point of view, which specs will be tested with SDF? OCF, Zigbee, etc. Whether definition and formulations work. Ari: also IPSO/LwM2M Koster: Google/Nest, smart things. Need also good support for evolution. Zigbee light bulbs don't behave same now as 4 years ago. IKEA for example wanted to remember brightness. Pattern changed. Initial validation hopefully will have models we can test with; maybe need also more speculative models. Lifecycle also interesting how to do well. Zigbee good example; has gone through a few times. ## OneDM status, process, formats, examples (Michael Koster) (lunch break) ## OneDM tools demo (Ari Keränen) See: https://github.com/EricssonResearch/ipso-odm Contains ipso2odm for conversions, ipsoidmapper for protocol binding files, odmlint for checking validity of SDF files. Carsten: need also better ways to check models: "code smell". McCool: validating extensions challenging in TD Carsten: With XML all extensions in different XML name spaces. Data modeling language needs a way to explicitly tell extension points. Interesting question: can you automate finding the data model definition of the extension? McCool: tools like SHACL can do some validation. But no clear definition how to get SHACL definitions. Static and dynamic validation. Fuzz testing: using schema to develop valid input to test implementation. ## OneDM WoT integration (Koster) Working on proxy for Web of Things. Protocol bindings for OneDM. Could use WoT TDs and tools that exist for that. For example IPSO devices working with OCF application via a proxy. Exposed things with OCF bindings and consumed TDs with IPSO bindings. Another thing, converting OneDM to RDF. Have some tooling for iotschema to RDF. Have namespace for iotschema definitions. Could extract/translate OneDM definitions to iotschema definitions. McCool: challenge see here: mapping high level patterns. RESTful vs pub/sub for example. No clean mapping between. Eliot: something YANG had to struggle with. Maybe worth looking at YANG for that purpose. Koster: we also have experience with mapping interactions to emulate with MQTT. Read/write and pub/sub for example. Most IoT devices have affordances and interaction models that are quite similar. Ari: could work on semantic proxy in hackathon? Koster: yes, working on RDF conversion. See also link to virtual thing. Could use that maybe. McCool: simpler case to generate TD from SDF file? Koster: yes, simply using URIs too. Could explore further. McCool: could simply have link to points to definition, would be useful in many use cases. Other use case: SDF RDF compiler. If want to pull TDs to RDF database. Koster: in TD have URIs pointing to common definition. McCool: could be type of link that makes it explicit that defining type of thing. Ari: will be working on this at hackathon; all welcome to join Carsten: also formal languages work happening in hackathon. Good to create mutual awareness on challenges and solutions. ## Coordination with W3C WoT and T2TRG (McCool) At WoT often get to topics that overlap with CoRE and T2TRG. Want to find right ways to do this together: * Complex interactions. How RESTful interaction used in practice * Discovery and onboarding. Appears in many places. How we accommodate different kind of discovery. In WoT have been in general descriptive, not prescriptive. Re-evaluating that. * Security schemes like OSCORE McCool: Complex interactions; when read TD get the impression describes all actions. However different states in interaction. May have information about the next steps. Could be list of things to do next. Today don't expect full web site in single HTML file. One option: TD like HTML file that is context and history sensitive. But conflicts with TD being API documentation. We could have static TDs, but to handle RESTful things would have to describe full state machine. For example, if POST something to create new resource, is that new property to show up in TD? Current state could be reflected in current affordances. Complicates caching etc. Hypermedia controls is idea of not TD having all possible interactions but primary entry points. Could invoke action and get back new TD. More like HTML is used. But don't have complete set of documentation. Eliot: when have new info to return; have thing and consumer. Thing publishing back? McCool: thing described by TD Eliot: consumer needs to know that result of RESTful interaction. How consumer learns of new TD if not coming from the thing? McCool: for HATEful thing it would come from the Thing. Maybe need a subset "interaction description". Eliot: is this something one could reasonable expect thing to do? Or to appear on intermediate device? McCool: depends if device is capable enough to generate JSON. In general easier than consuming. Not that difficult. Eliot: need to have state in the RESTful interaction with thin McCool: yes, general pattern. State is carried in the links you follow. Expectation that TD is documenting all interaction is no longer true with dynamic TDs Milan: violates the statelessness? Not sure what problem solves? McCool: RESTful means state is externalized. State is not in the device. If do hypermedia approach, may want to have thing template for each type you could return. Fill types during exec phase. Matthias: confusion with state here; IoT device has state to know if light is on or off. This is restful and can model this. Klaus has proposal for CoRE media types you can use. This you could put into TD "this is RESTful interaction" and "this is apriori knowledge you need". McCool: lot of the statelessness comes from scaling. IoT device don't have that context. Externalizing state is not necessarily applicable. Milan: cognitive load the device has to track doesn't scale Matthias: that's resource state, not per client state McCool: only one consumer would access particular state here CoRE has several discovery mechanism. Also have DNS-SD, Bluetooth beacons, etc. Want to take 2-phase approach. For CoRE RD use just as introduction or also as directory? Should RD do semantic query? How protected etc. Possible to use just for introduction. Maybe should be CoRE RD with extra functionality? Maybe just plain web service (Carsten: like RD). Eliot: another approach; have QR code, then don't have to worry about authorization. File is going to sit in Internet. Don't need to have auth mechanism. Koster: whether auth required, should be separate issue Eliot: but it's not. Directory service should support -- if something is posted that required - JC: depends on sensitivity of information McCool: can't be blanket statements. This is in requirement collection phase. Eliot: assumed CoRE? McCool: because at IETF. Want to answer if CoRE satisfies our requirement. Reasonable to put TDs in RD? CoRE auth control powerful enough? Eliot: no single answer. Could put file out in the Internet. Carsten: assumes you have Internet access. Eliot: not unreasonable to put schema to Internet. Unreasonable to put instances. Does it make sense to have class available as reference point? With some filled in info. Carsten: RD is template. We left the issue of access control model open. Have to combine with AC model. RD is designed to be local. No problem when Internet access goes away. Various ways to find RD. But finding separate from trusting. You could get TDs directly but if that's a good idea needs to be discussed. RD can provide links. Eliot: want to bring in another SDO. Discussed in Fairhair context. IEC 6443(?). Notion of security zones. Stamped in to certificate of RD authorization name. That name also part of bootstrap phase. Solved the problem in context using BRSKI. Could also use other mechanisms. Could be another SDO alongside with OCF. Could be informational doc to describe CoRE RD bootstrap. Even know candidate co-author for that. Volunteering someone who not here. Carsten: RD in IESG now. Eliot: added on top. Let's have MUD table next to WISHI table. McCool: interested to explore RD Carsten: we should try to find out what we actually need as opposed to putting bits and pieces together. Jennifer: wondering is standardized error codes for various things? McCool: in profiles looking at how to handle error codes. Currently not in TD but something planning for next round. One deliverable is update to TD spec. Jennifer: have few use cases with autonomous devices with battery, could be online in weird error state. Would be good to have reques/reply what is wrong with that. McCool: lot of devices handled by proxy. Could be various error cases there too. Eliot: take out word error and say status. Any modeling language with operations state would cover that. Carsten: have lots of bad experience with standardized error codes. Standardized information more useful. Looking into adapting something like that into constrained space too. Will be a draft how to do that. Eliot: covered in RESTCONF Jennifer: HTTP status codes very general Carsten: HTTP codes can't tell about errors in application, only in HTTP Matthias: need to look into application semantics to understand what went wrong McCool: in hackathon have couple of different paths could look into. ## Data model versioning (Carsten Bormann) Carsten: WISHI calls have interesting segments, including the discussion we had for versioning. Unfortunately we don't have time for this today. ## How do we enable connectivity: bootstrapping authorization, deploying identities and ridding the world of passwords (Michael Richardson) My connectivity is way too poor to present remotely. It is just unworkable. Here is an 11min video on how BRSKI relates to ACE and WoT. Eliot can answer questions about this: https://www.sandelman.ca/SSW/talks/deadParrots2019/t2trg-video1.mkv or: junk.sandelman.ca/junk/t2trg-video1.mkv McCool: the onboardin process does require Internet access? Eliot: only voucher. May be received from Internet or out of band. McCool: could batch bunch of requests to USB device (yes) Eliot: ANIMA/BRSKI is in final stages. View that as base draft. Another draft in EMU that shoves this all into EAP. That's the next step. Alternative: if we just use device provisioning protocol from Wi-Fi alliance. But nothing simple. Wireless devices need to select frequency or SSID. Similar in LoRAWAN etc. Wi-Fi alliance looking at standardizing chirp-messsage. Could be fingerprint of ID. As alternative for hunting all devices in all frequencies. Said to Wi-Fi alliance that what ever onboarding you start with is not the one you end with. Chain of events. What's responsibility of different devices and SDOs. McCool: what about opposite to onboarding; revocation? Eliot: easy too. In any large environment will have CMDB. When see hacked device, between CMDB and auth -- you will flag the device and depends what device is doing how you handle a device. If it's furnace, you want to be careful pulling the plug. Someone needs to make intelligent decision. Could unplug, defer, quarantee it (restricted network). Also if you sold the device to someone, what happens next. Any mechanism without bearer-token of some sort will not fly. People will lose / forget how to do things. No owner system available. How to get owner tokens to next step. Weakness of these systems, when have system integrator change. SI4 is the only one touching customer network. SI1 doesn't know SI4. SDO comes closest for showing ownership transfer. Blockchain does it but has its own set of problems. MJ: wallmart is really asking things like that. They use blockchain from IBM. Eliot: online vs offline transaction. Blockchain works for online. McCool: two ways to think of blockchain: public database or chain of signed things. Eliot: Blockchain is overkill for this. At least for the time will need to implement several mechanisms. Question is which of these. Next week will be discussing how to simplify this. Other thing: if provisioned with certificate; like the idea of signed attributes. It has expiry date. Question is how I re-provision. Have spent lots of time in TEEP discussing this. At least two levels of complexity: capabilities device could have and needs for deployment. One deployment may want to work with your certificates. McCool: complexity exposed to users is problem. Eliot: we at networking world screwed this up royally. Different things for home and enterprise. Didn't get that right. MJ: when were doing media streaming, had similar problems. Having to go back to original owner of the content. McCool: some people at W3C event very upset on the topic during discussions. Eliot: before getting ANIMA approved needed to show manufacturer going out of business, if device ever onboarded, would need to be able to be re-onboarded. Technology dimension and market-by-market (consumer, enterprise, industrial, mobile), we had to slow down how we do onboarding because taking time. Mohit did great work presenting EAP-NOOB. May be perfect way forward. EAP very modular. DPP throws monkey-wrench here. Basic concept is QR code as example. Got it wrong when suing 802 frames, only late supported by Android, not yet iPhones. McCool: we need to modularize the problems. Onboarding in state of flux but the outcome, having keys, more clear. Eliot: there's network onboarding, then decommission. Have to look at SI state. McCool: need standardized lifecycle model Carsten: IETF SOLACE presents a lifecycle. Stages you have to think about. McCool: in WoT need lifecycle, but don't want to re-invent wheel Eliot: NIST can help there. ## Configuring Time Sensitive Networking (TSN) from W3C WoT Thing Description (TD) (Matthias Kovatsch) Working now on TSN, related to DetNet (L3). OPC foundation is having new activity; so far working on management layer. Could be done vendor independent in OPC. Underneath full bunch of different systems. Vendor lock-in. Idea for OPC-UA going all the way down to connect different vendor techs. Base real-time performance on TSN. Gives you vendor-independent stack for IIoT. Good use case for describing existing ecosystems. Most of the connectivity in industrial still wired. That's why TSN with Ethernet important target. You have to configure connecvitiy. FLC: field level connecitivity now going down to devices. Have been working on how to describe this with thing descriptions and use with network config. Strong typing in OPC-UA. Inspired by the web but made more complex again. Have bidirectional references. Have to deal with bitmaps and word sized. Lots of friction created if want to describe with newer techs. OPC-UA hasn't registered anything with IANA, in old docs have opc-tcp etc but only OPC host server. From there nothing defined. (see slide 5 for mapping) TSN ecosystem built around 802.1Q spec. VLAN headers used to encode priority and other features needed for deterministic traffic. At trunk connections can reserve bandwidth to make sure important things like control signals are not dropped. McCool: TSN needs guaranteed latency? Today not in market TSN enabled endpoints. They could do way more; synch application to network access. Could have jitter guarantees, isochronous network access (application aware of the time in network). TSN capable devices have 8 different queues. Can assign specific traffic to specific queue. Can define timestamps when each gate to queue should be open or closed. Get traffic class windows. Or frame isolation. All started with audio and video traffic shaping. Now precision time protocol used. Still allowing best effort traffic. TSN also technology that allows you to converge network. Kaz: working for the W3C Media group as well as the W3C WoT groups. The Media group has been discussing how to deal with multiple video streams and how to synchronize them using some specific events and time code. So that discussion might be interesting and useful for this mechanism as well. Proposed further collaboration between Media group and WoT group during TPAC in Fukuoka in September. Different approaches: centralized, distributed, hybrid (slide 8). Usually NETCONF used as defacto standard for configuring network equipment. Also need OPC-UA binding for WoT. Have NETCONF WoT binding (see slide 9). Eliot: what config parameters? OPC-UA gives application. This (slide 12) not modeled in YANG. Eliot: why OPC UA on the slide? All different vendor specific protocols there. Now convergence with OPC having broad base. Have something on field level; TSN as basis, OPC FLC on top to have application convergence. All big vendors there. Eliot: OPC FLC delivers TSN slot info? Have different classes; parameters for selection what industrial app to configure on network level. Eliot: how dynamic is this? Really configuration. Multi-layered. Interesting to look at industrial IoT. Devices of the shelf have minimal config. Need engineering tool that used to model more dynamic parts. Which controller takes care of which devices, etc. When apply off-the shelf components to produce car or bread. See that coming more and more dynamic. "Batch size 1" new thing here. Also predictive maintenance use cases. McCool: nice to coordinate our efforts with OneDM too. Currently side project. Visiting researcher doing this. Have implemented the actual PLC mash-up application. App fetches TD as usual, but enchanced with QoS capabilities from infra. Matched with application QoS requirements. How often want to control robot arm, etc. When made choices, can talk to controller app that pushed a schedule to network. NP hard problem to come from requirements to network config. QoS capabilities (slide 14). Will have full list in the paper later. These will be Capabilities of the things McCool: looking at packaging for capabilities in WASM ## Manufacturer Usage Descriptions (MUDs) (Eliot Lear) The designer the only one who gets to decide what protocols being used. For example printers using Jabber. Admin will have hard time figuring out what kind of access they need. Devices will not be able to fully protec themselves. Important for device vendor to help network so that network can depend the device. Things will have very little programmer time. Needs to be simple. Network adming gets to eventually say what access the device will have. Any vendor who claims their device is secure, is lying. Manufacturer is the best in position to enumerate the use cases. Result: devices are segmented based on their use. Mudmaker.org can help creating MUD files. Can visualize with tooling. Mud characteristics: MUD configures network, not devices. Devices requires no understanding what MUD file does. You can use what you want and discard the rest; e.g, use just to classify devices. Device doesn't need to emit MUD URL, could be label scan or BOM import. Focus has been so far L3 access. Need to improve on automation; drafts on this. Would like to see more integration to consumer space, MCR working on this. Need to look into reporting tools: need feedback if device getting access it needs to have. Have good functionality in 802.3 and .11 networks. No reason why can't do on LoRAWAN; have ideas how to do it. One way looking at is TSN. Matthias: still application important, OPC based solutions promoted. Other application centric use too. What is the universal interface available. Jaime: understanding that DHCP option send MUD URL, before get IP address. No promises made by MUD Jaime: could get MUD, then network address, and then policy applied. RFC mentions CoAP once; CoAP URL. Why not expose MUD file as CoAP resource. Eliot: only reason; don't assume particular capability for the device to provide MUD file. First assumption: devices tight on CPU and memory and not able to do that. Also DHCP and LDP are second best for getting MUD file. Out of band or certificate are better ways. You don't want the assertion coming from device, but from manufacturer. Jaime: MUD file could be signed by manufacturer Eliot: it is. Write I-D; encourage that McCool: from type of device could find MUD file. Eliot: if I'm discovering MUD URL out of band; could have extension that points to TD. Will not have instance information there. McCool: could also link to MUD file from TD Eliot: encourage that JC: backward compatibility issues with evolution in the network? Eliot: policy is abstract. Device may gain new funtionality. MUD file has cache value to go check out if new behaviour added. McCool: also implies SW version is part of device type. Eliot: here folks in chip business can help me out. Know you are looking for ways to update certs based on hardware. Took me two years for dev vendors to emit URL. That's how difficult it is. One of the goals was using existing interfaces. Effort for implementors but also security issue. ## Thin ICE and semantics of connectivity candidate exchange (Christer Holmberg) The Thin ICE concept discussed before but now more IoT/CoAP related use case. (short ICE intro) about finding connectivity; IP address I can use. ICE has specific protocol and infra for finding out candidates. ICE doesn't dictate candidate exchange mechanism but SDP used commonly. Thin ICE is using CoAP to implement ICE. To re-use CoAP network stack and infra. CoAP GET to T-STUN server to get server reflexive address and subsequent requests to maintain binding. The candidates can be exchanged as candidate resource links, or as part of URI of link. Matthias: what ensures NAT keeps port open? Will have to send keepalives to T-STUN server. Matthias: every 10 seconds? With PCP or similar would not need. Eliot: looks like rreally stong argument for IPv6. IPv6 does reduce the need. But not remove. Bill: some architectures in IPv6 require ULAs. Eliot: binding to ULA can last for long time. Carsten: how device #2 find out the new binding of #1? Device #2 would ask, just in case, if #1 has candidates at RD Carsten: could also observe that (yes) Carsten: how find out that RD has T-STUN service? Discovery. T-STUN server just CoAP server that hosts a resource Carsten: so resource type in the draft that doesn't yet exist McCool: intersting you need to discovery it outside of your NAT Carsten: inside RD could have link to outside RD/T-STUN server McCool: a lot depends if your network cooperates. Eliot: you should publish something on this to make people convinced they should do IPv6. All sorts of liability issues NAT brings. Lack of transparency and all. And reliability. McCool: interesting here to analyze failure modes. NAT reboots, changes state, etc. Also cost of using regular ICE compared to this. Bill: will need to trust the STUN server gives you right address. Otherwise DDoS attacks possible. In STUN have authentication; could look into that here. Carsten: something we could do in CoRE as extension to RD Eliot: writeup with couple of use cases. Here or in CoRE. Good intro to spec work. Having use case out there good. For multimedia not sure if needed, but if there's real IoT use case; I suspect that if cross NAT boundary, really want to do a cloud based rendezvous. For most use cases where NAT involved, have resource advertized through cloud based service. Only time when doesn't work when vast amount of BW involved or latency problem (greater than 100ms). Challenge is if there's real use case. WebEx video goes via central servers; nothing goes p2p. Something in industrial setting or smart city? McCool: even in smart home see lots of verticals going to cloud. Often behind NAT and if multiple segments in home network. Eliot: good reasons for going via cloud: reduce device effort. RD in home not sure. For industrial automation use case stronger. Don't see happening in home. Lots of closed ecosystems. There is benefit if can reduce memory usage bt 60-80% and processing requirements and hence power. McCool: not sure you reduce effort by going to cloud. Need more complex stacks. Eliot: researcher in Berkeley looking into this (to be continued over dinner) ## Discussion ## Wrap-up and close (all) MJ: really good to have real use case and show how different models work in reality. Lot of stuff theorethical. For example one industrial example. McCool: agree; hackathon still somewhat artificial use cases. Some use cases take years to evolve. Getting involved with Singapore smart city good. Jennifer: any groups or companies using established WoT standards McCool: WoT just finishing standards. PoCs available and things in works. Next steps getting to products. Jennifer: how long will take? Months? Years? Eliot: some of it is done. McCool: a new revision in a year or so. Some parts done, like many CoRE things. Other parts not finished yet. One thing working on for WoT is to integrate with stacks like AJAX to have rest of the pieces. Jennifer: institution where to use and implement these standards; the only difficulty if the group has built around old version. Early adoption could run to various issues. McCool: early adopted has some risk. Why to do relatively small scale PoC to see it works. Eliot: some of this could work with your vendors already now. With MUD, even if don't automate anything, having declaration from vendor of what kind of access devices require with formal language is useful. McCool: Thing Description is also formal definition of how thing behaves. Eliot: idea of software BOM; if have IoT device that has large amount of SW components. How do you know about vulnerabilities. Carsten: COSWID solves some of that Eliot: how SW BOM help build thing description or vice versa McCool: tooling to do automated auditing; but general problem how we avoid re-inventing the wheel. Standards landscape is complicated. Have spent lots of time just to understand what is out there. Eliot: could imagine TD, generate intermediate form of MUD file from that. Based on the protocol bindings: here's the access that's needed. MUD is based on access control model. Milan: articulate system requirements and assumptions in flows; building or buying devices. If building, choose similar standards and get architectural and philosophical guidance and alignment. McCool: useful for us documenting requirements. Jennifer: concepts for using WoT model; having examples that it "works this way" is useful. McCool: have had plugfests with hundreds of devices. Can post pointers.