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
● 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
● 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.
● 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
● 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.
● 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
● 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
● 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.
● 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.
● Carsten Bormann: Lighting Controller
● Matthias Kovatsch: Bulb, Controller, Visualizer
● Michael Koster: HATEOAS discovery and control of a connected light bulb
● 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.
● 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.
● 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.
● 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.
● 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
● We seem to have good overlap of people contributing to different organizations already
● Trying today to get more alignment and understanding
● 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.
● 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.
● 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
● 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.
● 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.
● 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?
● 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