Minutes of the face-to-face meeting of the Thing-to-Thing Research Group (T2TRG)


Tuesday 16-17 March, 2016, San Jose, CA
Chairs: Carsten Bormann & Ari Keränen

Note takers: chairs, Matthias Kovatchs, Jaime Jimenez

Tuesday, 16 March 2016

Welcome: Carsten Bormann

      Now an IRTF Research Group (not “proposed” anymore)

      Introduction round

      Areas of interest and objectives

      Hannes: are there documents about reference environments etc?

      Carsten: Number of documents from the RG; no single T2TRG doc

      Hannes: Value for enabling plugfests in general. For example DTLS profile testing.

      Kerry: taking further to full profile with test suites etc. would be great (ZigBee IP is a good example for a full stack description). Open source community dying to have something like that.

      Robert: It is good to have a specific target to do a profile (as we had for ZigBee IP)

      Carsten: ETSI happy to run tests like that. Suggested for DTLS already. Hesitant to go where lots of web activity ongoing. Constrained space better.

      Christian: Is this related to oneM2M?

      Carsten: Plugtest activity is unrelated to oneM2M.

      Carsten: Several alliances are not specifying the basics like joining a wifi network and focusing instead on other problems.

      Plan for the coming days

      Wednesday afternoon together with OCF

      Wednesday morning tackling Bluetooth and related

      Will move Robert C and ZigBee CL to Tuesday afternoon

      Relation to IETF WGs.

      Relation to IAB (Workshops).

      Focus of this meeting: Semantics and Data Models (proximity to IoTSI)

      Kerry: T2TRG is now official? Will there be colocated meetings at IETF meetings?

      Carsten: Yes. Buenos Aires will have summary and Berlin is very attractive, but not finalized yet. Could join RIOT Summit during an open day. Let’s discuss during wrap-up.

      Kerry: Good confluence with university researchers.

      Kerry: Will there be time-driven goals?

      Carsten: We should. I want to see a timeline for what is already on the slides.

      Agenda bashing

      There is time in the plugREST slot

      Wednesday not fully planned yet, but need time for wrap-up and transit to OCF meeting

      Where are we now? Able to “connect” to the IoT (“IETF stack”), but need to work on meaning, interactions, security, and evolution

Ari Keränen: RESTful IoT Design

      Need to work on the “HATEOAS” branding; “hyper-media driven” rather than the acronym

      Draft not that widely known yet (audience questions)

      JinHyeok: A lot of confusion about terminology. Are representation formats related to the consortia data models

      Kerry: Need to define what is missing for representation formats. JSON schema etc. appears to get a lot attention.

      Michael: CoRE Link Format and SenML are good examples

      Matthias: JSON is just a serialization format, it has no meaning. The hard part is to define representation formats that are reusable, not tied to a specific consortium.

      Ari: How do we achieve this?

      Matthias: There is some sweet spot between the simplicity of reusability and conveying sufficient meaning.

      ?: JSON is a good starting point because people know it and it has plenty of tools.

      Kerry: As a RG we could pick one and see how far we get

      Kerry: Enumerate the degrees of freedom we have to see what we can work with

      Robert: Should be careful about the level of detail (see XML work in the W3C), more ad hoc may be better

      JinHyeok: Key value pairs are good to structure data, which in turn nicely maps to JSON

      Kerry: REST appears to be just one layer below the semantics

      Ari: What would be a good level for guidance

      Carsten: We should work on a consensus inside the RG. Disagreement often comes from different experience (which are good to share)

      Kerry: Where to define relation types?

      Ari: Should be another document

      Christian: Should we start to define resource hierarchies?

      Ari: This is a complex discussion, for instance, it is bad to make assumptions on the client side about the structure of URIs.

Matthias Kovatsch: Semantic Interoperability Requires Self-describing Interaction Models

      Information Model is required to know the “what” about the information.

      Interaction Models are the “how” about interoperability. The challenge is not descriptions on the server side but having the client side to consume it.

      We need a model that supports evolution over time.

      Hannes: Bluetooth defines characteristics and service; with new service can be designed in a way that new service includes old one as sub-service. Also delta advertized. New system would used composed service.

      Kerry: Z-wave has similar approach. Can also be evolution of schema, delta from one to another.

      Common recurring pattern. Need to figure out how to use it properly. The way the web maintains backwards compatibility.

      Hannes: the HTML and browsers is probably not good example; 90s browser can’t use today’s web pages. Although there are no-frames etc. methods.

      Matthias: Not the new features, but still the basic features (forms, links, data/text)

      Hannes: What is then the role of the SW update then?

      Matthias: Probably will not work with billions of devices from different manufacturers

      Kerry: Devices should be “updatable” otherwise they become insecure.

      Semantic interoperability WS summary: Need for meta-models.

      Hannes: For example, LwM2M XML schema is there to help developer. HATEOAS interaction model is runtime mechanism.

      With IPSO objects need to read spec to know what each number means

      Kerry: Is there data model under this layer? Can be abstracted away with RESTful model? Something customers interested.

      Vendors not keen on using single data model. Something like semantic web and ontology matching can help.

      Hannes: would like to have simplicity of mapping one island to another, be it Z-wave or ZigBee. Gateway vendors can benefit from chaos.

      Kerry: Underlying devices are becoming more RESTful over time. Simplifies mapping problem.

      Robert: Yet another standard is not likely to help; “one to unify them all”. Bit utopian.

      Matthias: Want to go into identifying commonalities in the descriptions. Domains can keep vocabulary just how to work together. How to make different models fill the common patterns.

      Carsten: Sometimes utopian ideas work

      Matthias: Hypermedia Driven REST could be a better way to call it.

      Matthias: Summary HATEOAS Interaction Model. Vocabulary is agreed beforehand. Relation type vocabulary is giving it meaning.

      Michael: Schema.org one clearing house for connecting terms

      Jaime: How to tackle slight differences. Composition model instead of classes helpful.

      Hannes: What scenarios addressing? Different from home to industrial. Dynamic, learn-on-fly, can scare industry folks.

      Matthias: Industry 4.0 folks want to have dynamic systems.

      Michael: Reconfigurability important for workflows

      Jaime: It could be interesting to build a crawler for this, browsing all links similarly as the web does.

      Matthias: LwM2M is a half-way solution. You still need some guidelines. The URI is used to encode this kind of vocabulary, but that restricts you how you form the URI. That’s why you need to decouple it so that manufacturers can choose

      Matthias: Web mashups example. If some service changes the API, the device doesn’t work anymore (fridge example). 

      Matthias: CoRE-HAL,  Application Data has to be known.

      Hannes: Dan elide e.g., links and forms if only data is interest?

      Yes, bookmarks etc. help here

      JH: plans to extend beyond 5 methods; e.g., PATCH?

      Matthias: Yes, work on PATCH ongoing. And forms too. Maybe have this in OCF discussion. How to use forms.

      Carsten: This just shows a possible way forward, not the only one

      ?: RAML and JSON Schema are used as mandatory features. Sometimes we need different schemas.

      Matthias: Actions are not currently in OCF, they should extend it. Forms are a good way to formulate interaction.

      Matthias: CoRE-HAL Explorer & Hypermedia Client Futures.

      Carsten: Some Future implementations have the cache staling functionality. The concepts worth exploring.

      Matthias: ThingCrawler.

      Matthias: Tradeoffs

      Carsten: What are the worst things about HAL?

      Matthias: No relation types, no form support.

      Michael: Converting between strings and arrays is fine; but need to do one way.

      Carsten: Need to decide for the JSON and CBOR link format. And need to get OCF et al to follow.

      Matthias: Need exercise on the order preserving functionality

Michael Koster: Research Topics in Machine Hypermedia System Design

      Design patterns for interoperable hypertext

      Reference architecture (client is the hard part).

      Christian: What is “Resource Application”

      Michael: Application logic, device driver, the part that actually does something

      Matthias: Need common terminology here

      Hannes: +1 to terminology

      Content format: defines a common interaction model with links and forms.

      Jaime: What is hsml?

      Michael: my format presented here, based on SenML

      Hannes: Data and metadata should be separated to avoid overhead (caching)

      Michael: Use different representations (only data, with metadata, only …) (->content negotiation)

      Hannes: It depends on the use case. For some it might not be useful.

      Michael: This can adapt to any use case by choosing the right representation format

      Jaime: What is the difference to CoRE-HAL?

      Michael: Basically the same, just a different format

      Matthias: Semantically the same

      Kerry: Is it a general assumption that clients are more powerful?

      Carsten: In IETF we assumed clients are

      Kerry: Then we should solve the problem of the format.

      Jaime: Is there a reason why we maintain so many formats?

      Matthias: We are exploring, there is no “best format” right now. We will see in the future.

      Hannes: Maybe we don’t really need that many formats. Comparable experience with protocols shows that not many really ask for HTTP or MQTT in mbed OS.

      Forms

      Offline descriptors can be used to define these online formats

      Relations, some types are already defined in this framework

      RESTful asynchronous communication (e.g., observe) and bindings (through an implicit client between resources)

      Hannes: Mobile-code based approach?

      Matthias: That only shifts the problem of interoperability elsewhere. You need to know exactly the device properties and send customized code to that client.

      Carsten: Problem: some notifications are for state change, some are for standalone events; the latter are problematic (in particular managing the volume). Atom solved this by limiting the number of events stored in resource state. It is an inherent problem of event-based systems. Depends on whether you can lose some events.

      Promise+

      Carsten: The software “observer” design pattern has always been the basis for CoAP Observe, thus this API fits so well

      Carsten: HTTP/2.0 base has the required mechanisms

      Michael: So far nothing in place to just use. Needs additional specification work

      Updating physical state through resources

      Hannes: There might be something to learn from the management guys. They also have this notion of delayed realization.

      Carsten: In management this coupling between intended and actual state.

      Carsten: Something we can learn are atomic realizations of multiple configuration items (modify (copies of) resources until ready, then apply)

      Intended state and actual state has some problems with observability of the state transition

      Carsten: Problem with actions that combine in a result

      Michael: This is just a pattern. Use what fits best the physical process.

      Robert: ZigBee had the “manipulator resource”

      REST Protocol Abstraction

      Cross protocol hyperlinking, using consistent URIs

      Carsten: People choose CoAP over Websockets. Without HTTP

      Hannes: But if it does not support HTTP, it is not really that. Besides why would you make a device run HTTP.

      Matthias: They use CoAP over Websockets because the latter provides a tunnel through NATs, firewalls, etc.

      Domain Model

      Mathias: Similar to TD, there should be alignment on the vocabulary used.

Carsten Bormann: YANG, CoMI, COOL: Managing IoT in a mostly RESTful way

      Managed vs. unmanaged

      Need to design for choice

      Hannes: More a business model decision. Choice is just an illusion

      Robert: It is more about how many people can do “management” by themselves

      Christian: There are many different specialists, to which people go

      What is the incentive for this? (laws?)

      Management systems show that there was incentive to open up management interfaces (provide choice)

      Need to have swarms of devices alike and to know what devices can do, devices themselves still discovered during runtime

      CoMI mainly about compact identifiers → hash text labels to 30 bit IDs

      CoOL about managing the label IDs (“SIDs”)

      How to manage number space for different YANG models? Needs a registry-like mechanism for “SID” entries

      Management items are usually large collections: FETCH/PATCH, maybe even patch notifications for observe will be useful

      Christian: Can this configuration/management also help with providing more context information for the application?

      Carsten: Usually modeled as “view”, which could be configured

Klaus Hartke (presented by Carsten): CoRAL

      Hypermedia-driven REST comes at higher cost (design effort, roundtrips, representation size)

      CoRAL looks at optimizing representation size

      CBOR encoding of links, forms, embedded representations

      Numeric IDs for relation types etc.

      What Michael was doing for resource types; here done for relation types

 

Qin Wu: Strawman proposal on Network Telemetry and Analysis

      Device management also needs a big data approach: data analytics, profiling

      Network telemetry is about data distribution and processing

      Hannes: who is the one using the Fault Localization and Diagnosis, the operator or the main user?

      Qin Wu: Could be either.

Robert Craige: ZigBee Cluster Library

      Documentation available, can be implemented for free by non-profits, device manufacturers must join ZigBee Alliance

      Clusters are re-usable elements, lots of definitions available (14 years of work)

      ZCL needs rework to be more suitable for IP

      ZCL over IP uses CoAP and CBOR, not custom UDP binding

      Michael: So it is URI and attribute mapping and it is done?

      Robert: Yes. Discovery and security aspects are supposed to come later

      Christian: What are applications profiles?

      Robert: Traditionally profiles which clusters are available. Not that central anymore; wanted to get out of silos. But there are of course big differences between domains.

      Carsten: What’s the timeline of this being ready?

      Robert: End of the year. Before then available only for ZigBee members

      Carsten: Would be interesting research to try to RESTify the whole ZigBee cluster

      Robert: Was discussed in ZB, but was deemed too much work considering the resources

      Michael: Lots of good stuff in ZCL, for example the lightning library is widely used. For example RGB seems good model for lightning control, but industry experience shows otherwise

      Matthias: Is this related to [specific IoT] alliance? They are going to RESTful model. Doing this as thing description would be good input for W3C WoT. Someone willing to come to WoT meeting.

      Robert: There are common members. Maybe someone could join.

PlugREST Session

      Carsten Bormann: Lighting Controller

      Matthias Kovatsch: Bulb, Controller, Visualizer

      Michael Koster: HATEOAS discovery and control of a connected light bulb

Hannes Tschofenig: Introducing Server Name Identifiers in Certificates

      Need new field in certificates for IoT devices; filled with endpoint name as used in RD

      Why use certificates at all if there is no DNS name? Raw public key would do the job; could be provided by RD

      Hannes: Endpoint name is used as identifier. You can use hash of the public key too. 

      Robert: ZigBee used a fingerprint of the device as identifier and put it into the certificate

      Hannes: Do you use a special field in the certificate?

      Robert: Yes, one of the X.509 fields.

      Hannes: Each field has an assumed semantic meaning, so it is not advisable to add. Not good to put a MAC address there.

      Carsten: How do I find the root?

      Hannes: Trust anchor is preconfigured.

Carsten Bormann: A model for device-manager delegation

      Endpoint identifier not meaningful on its own; depends on the principals

      DCAF four leg model

      Protocol for T2T should be application agnostic (no business logic for authorization); managers use a protocol that enables secure auth

      Matthias: Semantics of auth* are only described at manager level; device level only has plain access control information. Where is the lifetime represented? Between endpoints or between the authorization mechanism between the principals (COP and ROP)

      Carsten: Managers might need to translate lifetime to something that works without clocks

      Michael: Object level security might be interesting to implement in current representation format prototypes

      Simple authorization information such as AIF model, which cannot describe payload constraints, might work. Sometimes easier to create a new resource for special payload aspects. You could create a new resource that has the authorization/access to other resources information.

      Hannes: RFC 2704 describes a language that could be used to be more strict and express complex conditions.

Wednesday 17 March 2016

Robin Heydon: An Introduction to Bluetooth low energy

      Bluetooth attributes are similar to resources in REST world

      Only one request-response in flight at any time

      Command and notifications don’t have response; can send any amount any time

      Can also send command while waiting for response

      Idea to reduce the complexity on server. No state in protocol at server.

      Commands and notifications not reliable. Indications are.

      Services are immutable; version 2 can only add optional characteristics. Or create new service that includes the old one. Can be multiple instances of a service on device.

      Michael: reference design implementation of gateway at the website. What is that for?

      Robin: Bluetooth SIG not allowed to define anything beyond what goes over the air. BT SIG can write white papers, but can’t ratify those. Would be great if IETF took those, improved those, and published as standards.

      Hannes: Metadata associated with the data; sounds useful for generic clients. But got impression that vendors seem to ignore that capability? Looking at wrong products?

      Probably looking at wrong products. There’s set of standardized services. Anyone can create UUID and create own service. For example, what FitBit would do. Use same characteristics, but will have own value UUIDs.

      Hannes: Some examples looked at did not provide metadata about presentation formats. Not ideal for generic clients.

      BT SIG uses SHOULD for suggesting to do that; some do, many don’t

      Kerry: How this relates to IPv6 over BLE

      Not related.

      Carsten: original IP over BLE spec was independent of this. The final was more so.

      Read characteristic value how to connect with IPv6. Then use L2CAP to connect.

      Ari: Difference between GAP and GATT?

      In BT1.1 standard set of terms and methods were deemed needed. That’s codified in Generic Access Profile (GAP). All about connectivity, discoverability, how to establish L2CAP, etc.

      GATT is about services and characteristics.

      Proper RESTful interface needs both. Need the connectivity part too, not just characteristics.

      In wireless world devices move; drop links etc. Need to discover devices, what services they have, and only then start using devices.

      Matthias: BLE hits more infrastructure IoT space. Is there roadmap where it’s going?

      Mesh network work ongoing. Built around pub/sub model. Can say more in about 6 months.

      Security important here. Bluetooth IoT devices don’t have enough memory for certificates. Shipping billions a year of devices. One certificate takes 10 times the memory available in devices. Needs to be simple to setup, but still resilient against attacks.

      Kerry: End-to-end security not option in many cases. GW being “trusted” man in middle. Nordic has chip with NFC used for associating. Could be useful kind of paradigms.

      Hannes: Ongoing work at IETF to solve some of the problems

      Carsten: The RG is working on document on secure bootstrapping; useful to BT guys have a look too

      Robin: Writing RESTful API is the easy part. Can help with that.

      Could be kB of RAM in Bluetooth world. And that’s lot.

      Carsten: New chips coming out are coming with 128/16 (kb of Flash/RAM). Bluetooth chips with 256/16.

      Robin: Probably for Firmware OTA.

      Hannes: With Internet connected devices security is not free. Does not need to be certificate based. New Bluetooth spec support public key crypto too. HW based RNGs useful too, and chips seem to have it. And many have HW AES too.

      Robin: Past 3 years resulted in order of magnitude power reduction.

Carsten Bormann: BLE URI draft

      There is whitepaper for “RESTful API access” for Bluetooth

      The design was not quite RESTful in original definition of the word.

      Now looking into situation where BT device connected to proxy/gateway that is part of Internet and using BT as local interconnect with local devices. Assuming BT functionality that makes it secure.

      One way looking at: using BT as the last hop after IP. But proxy does not necessarily understand what the BT device can do. Try to avoid that kind of binding.

      Need way for the proxy to address things in BT device that is application agnostic.

      Wrote a draft about this; but not published yet since needs work to see it makes sense

      URIs for example for finding nodes. Return values more links.

      Ari: The draft is based on the published white paper

      Robin: Passive and active scanning not logically GET operations. Commands for starting to look for devices. Difference active/passive is whether to connect.

      Robin: MAC address of BLE devices is 49 bits. Bdaddress 7 bytes. Additional concepts beyond 48 bits. Private addresses etc.

      The media types need to be defined with the URI doc. Important part of RESTful design.

      Need to now validate the direction; is this good way to go?

      Didn’t yet do commands and notifications; how to do that in RESTful way

      Hannes: What is typical use case; GW using HTTP/CoAP and BT on the other side?

      And what is the name? BLE? BT Smart?

      Robin: BLE is name of the spec. Smart brand no longer needed. Should not use that. Take-off of BLE was so fast that every GW is LE-enabled, so no need for “smart” brand.

      Carsten: Use case to have REST reach over the border of Internet. Another view: BT device just part of GW via local interconnect.

      Kerry: How device viewed from Internet side in different cases?

      Similar. Thing connected to GW.

      But IP addresses are cheap and allocating one for each makes sense. Can have IP address for BLE device in the GW (not put as part of URI).

      Bluetooth likely to evolve more RESTful in the future

      Michael: In the draft schema is “ble”

      That would be for URI-proxy option and similar.

      Kerry: Exposing the underlying data model?

      Yes, some extent necessary. Needs to understand some amount of GATT.

      Robin: A device can be in range of multiple devices; all which can discover and enable device to be connected to Internet

      Carsten: At CoRE world we have RD. Gateway might announce BT functionality to RD. This way find the right GW.

      Robin: Any concept for quality of link etc?

      Carsten: No plans to do routing, but maybe could have that.

      Michael: Interesting idea. Someone proposed different quality index recently at IETF.

      Ari: What is a good way forward?

      Robin: Should do this at the IETF. Marcel and Victor from SIG right guys to help.

      Concept of doing active/passive scan; seems more like PUT. Can happen continuously in background.

      Matthias: Is this needed to expose at application layer?

      Robin: Some parts of discovery and connecting can be abstracted out. But concept of observing devices not. Someone needs to make conscious decision since that takes energy.

      Kerry: GW would probably be observing in most cases

      Matthias: Why bundled in the single API with different aspects? Could be separate operator interface for config?

      Robin: “Operator interface” would be GAP interface.

      Michael: Discovery operations would need GAP interface access.

      Robin explained difference between active and passive scanning (see slides); something you want to expose in the “operator interface”.

      Matthias: How to model the scanning operation. Current model is RPC.

      Robin: GAP state of the passive/active scanning to read and write. As side effect getting information about devices.

      For list of nodes: BT address is good, but information from advertisements is useful too. Populating advertising packets to internet directory would be very useful.

      Carsten: Need to continue the discussion. Also on security. For RG we need to figure out right people to reach out to. How to do this in regular way?

      Robin: Current BT SIG rules make this tricky. But issue has been identified at the SIG and working on ways to work more together.

John Strassner: Semantic Interoperability Using Models, Ontologies, and DSLs

      Many modeling languages do not provide calculus, mechanisms to check models or reason upon them

      Context needs to stay stable during analysis/reasoning

      Need a tangible definition of context

      Context allows to calculate cost in a better way (e.g., SUPA policy work)

      FOCALE

      Domain specific languages simplify task for domain experts

      Most data lacks semantic information

      DEN-ng open source project

T2TRG/OCF/W3C Joint meeting

      We seem to have good overlap of people contributing to different organizations already

      Trying today to get more alignment and understanding

Carsten Bormann: IRTF T2TRG Intro

      Disclaimer. Noted that formal liaisons are handled by IAB; and IRTF groups don’t have liaisons (but IETF WGs do)

      Daniel Park: Is IETF considering only for IPv6?

      Carsten: Many of the protocols are very flexible. Want to make sure new things work on IPv6, but IPv4 works too.

      JH: Is Thread following RFC 6775?

      Using 6lowpan but with modifications. Routing and 6lowpan layer different.

      Questions and items for discussion

      Dave Ragget: Is REST the right question?

      Carsten: REST ideas are trying to achieve specific benefits. Need to still evaluate if those benefits are valuable for IoT. REST evolves; e.g., observe as example. And there are many other ways.

      Dave: What should we be doing at each layer of the stack?

      ?: What protocols are appropriate with e.g., machine learning systems where you don’t have human programmer in loop.

      Carsten: REST interfaces would give many of the needed discovery functions

      JH: What other options are there?

      Message queues, buses, RPC, etc. And in between, such as CoAP pub/sub broker. Have to look at what type fits your problem. RPC is relatively similar to REST but provides strong coupling of endpoints; REST tries to reduce the coupling

      Dave Thaler: And named-data networking; not addressing endpoints but data. Ongoing research problem at IRTF.

Soohong Daniel Park: OCF from OIC

      All OIC specs are now OCF specs

      1st major unification: UPnP now one working group at OCF

      2nd major unification: Qualcomm, Microsoft, and Electrolux joining OCF

      Main activities: specifications and open source (IoTivity). Also certification (only members).

      Royalty free IPR policy with members. Open source Apache 2.0.

      Slightly different with OCF from OIC

      Independent of OCF membership IoTivity can be used freely. Almost all mandatory features are implemented.

Ravi Subramaniam: OCF spec overview; Technical Principles for IoT ecosystem

      Basic approach: declarative (cf. imperative) framework. Things defined as resources and properties.

      Kerry: need to support both styles or idea to use one or other?

      Intent to be specified declarative. Mapping to imperative needs to be eventually done but not as part of the specs.

      RESTful part: server does not maintain state. Every device in OCF model is client and server.

      Multi-protocol: can be run over various protocols (CoAP, MQTT, etc.) and peer-to-peer.

      Hannes: Taking security in account in peer-to-peer; is the model p2p anymore?

      Depends how you build hierarchies. If you communicate with other node, that is a peer (cf. cloud). Even if cloud needed for initial setup, it’s p2p in OCF sense.

      Support of multiple verticals in OCF, but also make different domains interoperable through a common platform

      Devices combine resource definitions (cf. “composition”)

      Framework should span from highly resource-constrained devices to bigger ones. Started with assuming 8-bit MCUs, but now moving to 16- and 32-bit.

      Lower layers abstracted away. Allows for late bindings and different transports

      Architecture

      Kerry: Is this an N x M problem where a consumer needs to care about the vertical? A temperature sensor is the same in any vertical.

      The description for correct interpretation comes from a specific data model from the vertical/context. This context has to be learned/discovered

      OCF well-known resources on a device: “core resources” and other building blocks

      Resource

      Link

      Collection: one or more references to other resources

      Scene: predefined set of values for resources

      Rules: If this then that

      Scripts: more complex ad-hoc rule sets

      (and Interfaces)

      Resource discovery similar to RD, but same interface for devices and directory

      Security was based on link-level security with DTLS but now adding access control to resource level. X.509 based methodology. Intent to use same declarative style for security.

      OIC device lifecycle: connecting, discover, establish, provision/bootstrap, discovery and normal operation, device revocation/de-provisioning

      Ari: What kind of identities are you using?

      UUIDs for unique naming, additional types such as certificates for authentication is ongoing work. The latter often only used for bootstrapping to get the actual identity. Various models on who creates the UUID; can be from manufacturer or generated on bootstrapping, for example.

      Hannes: Is real-time clock assumed on device? Period in access control JSON example. Have you defined a time sync mechanism?

      Darshak: Depends on the device. No mechanism defined yet.

      Dave T: How to figure out if supported? Mandatory property?

      Not completely done yet.

      Dave R: How do you describe security requirements (for the user)? How to bridge to usable security?

      Management of configuration resources works on that. Security parameters modeled as resources. Knowing the resource type allows for introspection. Goes back to declarative model: It is easier for people to describe what they need.

      OIC uses STUN and TURN and ICE lite. Currently for IPv4, not IPv6.

      Ari: Is there still ongoing work on the ICE?

      Currently hosted in the core group but no active work. But interest to get this working. Could be worked at the ICE WG of IETF.

      Smart Home use cases. A lot defined in RAML

      Darshak: oneIoTa is publicly on GitHub and holds all the detailed information

      No need to be member to use the oneIoTa tool

      Having something like JSON schema would be good to model the data representations

      SenML is something that could be looked closer

      Christian: Are you partnering with someone from the industrial side?

      There was work in the IIC. Are you thinking about something specific?

      Daniel: The idea is to collaborate with the IIC to provide something for industrial use cases

      Industrial is interesting because there are many protocols, data models, etc. with very specific requirements, foremost determinism. We are looking into DDS

      Kerry: Did you explore JSON Hyperschema?

      Darshak: Yes. In terms of modeling, RAML appeared easier. We wanted to separate resource model from implementations.

      Carsten: Schema for the values in data. Can you tell a bit about the problems you encountered?

      Some issues with time series and ranges

Dave Ragget: From WWW of pages to WoT

      Introduction, purpose (bridging silos)

      W3C intro

      Importance of Semantics (ref. to IAB WS)

      Looking into what is needed across SDOs to build semantic interoperability. Concrete steps to be taken together.

      WoT WG to be launched during 2016

      Ravi Subramaniam: Lots of overlap with OCF process framework. How do we work to not create yet another different things.

      Dave: If we want to integrate OCF with WoT, we need to have discussion on commonalities in semantics. Work together to identify common pieces. Need to figure out is the WoT model expressive enough.

      Kerry: Each horizontal/vertical metadata (slide 17) has different mechanisms inside. There's no value in 15 different ways to give temperature in celsius.

      Dave: Need to figure out best practices; weak coupling between organizations; need to talk about these kind of things.

      Ravi: Can we use tools like ones from OCF to avoid N+1 standards problem. Add rich semantics from WoT to OCF model?

      Dave: Trying to address this across organizations, small pieces at time.

      Need to collect use cases to figure out the right level of semantics. How far to go.

      John S: It’s about data model and vocabularies. How about scalability with incomplete reasoning?

      Dave: Need to be driven by use cases and market forces.

      John S: Multiple SDOs missing the boat with emphasizing the data, but not collection and data relations.

      Ravi: For making collaboration more concrete, could help with annotating the presentation with how OCF would solve them

      Carsten: Need to move on to next topics, but in the end make sure we have time to figure out to concrete steps for collaboration, such as RD extensions discussed during the break.

Matthias Kovatsch: W3C WoT current practices

      Collecting WoT building blocks and plugfest results to single document. Also getting-started document

      Uze Choi: What kind of protocols are supported by WoT architecture?

      Currently HTTP and CoAP, also work on MQTT with shim layer

      JH: How properties and values modeled?

      Still experimental how to do this

      Hannes T: How to read security part (slide 6). Who provides the info?

      The principle of the thing provides. Per thing. Bootstrapping and ownership phase for that.

      JH: can this be understood as resource: it’s metadata

      Dave T: Example of a possible instance, not general class.

      Dave R: At some stage want to build prototype, this example does not have too much semantics

      Matthias: Gives basic vocabulary and context. OCF could provide vocabulary to get semantics.

      Dave R: JSON-LD context provides bindings. Links to RDF triples. GW could download them, device probably would not.

      Matthias: Not a class model, but composition of concepts

      Jaime: OCF expected to populate the vocabularies (actions, properties, etc.); Do you already have some beta-repository of the actions that you are using or there is only very few examples?

      Matthias: Yes kinda, links at the end.

      Uze Choi: Examples of TDs for queries? As in querying all things that have a specific attribute and then actuating on them.

      Will take off-line

      Scripting API available (WebIDL for various scripting languages)

      Ravi: How data is communicated? Same protocols? What is scope of work. OCF work with Thing Description on top could be good use case

      Jaime: Is there remote participation possibility for WoT f2f meetings?

      Sometimes. Will look into possibilities.

OCF Alignment and Collaboration

      Carsten: Have found many commonalities. How to go forward with collaboration? Could try to come up with couple of items where we can have interactions. Core RD work, etc.

      Dave: Have whitepaper in progress where would be good to have OCF participants, as individuals, along.

      Matthias: Chances for collaboration: oneIoTa: RAML (vocabulary, JSON schema, etc); domain-specific vocabulary; CRUDN and protocol bindings (XMPP, BLE)

      Matthias: Problems: synch with IETF drafting work, e.g. CoAP over TCP work

      Carsten: Please send analysis of the TCP issue to CoRE mailing list and it will be discussed there

      And there are many other opportunities to pick up

      Ravi: Including core interfaces

      Dave T: For the editorial issues, please send to me (some are already on the list to fix)

      Carsten: oneIoTa work would happen on the T2TRG mailing list

      Kerry, Ravi, and Christian interested

      Carsten: Good to collect experiences, what works well what not. Some form of requirement statement could be done in the end.

      Ravi: RAML is under other organization

      Carsten: In research group we can discuss still that

      Carsten: When can we do this next time? Typically RG meetings co-located with other activities in same point of time. If OCF decides to co-located with other activities, that facilitates.

      Daniel: Next meeting end of June in Portland, Oregon. First week of November in Taipei. Planning for one or two additional in between.

      Carsten: T2TRG going to RIOT summit in July. Good to find places like that.

      Ravi: Could meet in Krakow, Poland in May?

Wrap-up

      OCF relevant organization to work together with

      Good to do outreach to make sure IETF/IRTF is understood

      Future meetings: planning to co-locate with next two IETFs and RIOT OS summit at Berlin