Joint T2TRG / OCF meeting
10th of March 2017

Attendance:

OCF:

Beechwood Software	Brad Kemp	brad@beechwoods.com
Cisco Systems	Wouter vane der Beek	wovander@cisco.com
Comcast	Achim von Neefe	achim_vonneefe@cable.comcast.com
Electrolux	Petr Tahal	petr.tahal@electrolux.com
ETRI	Joo-Chul Kevin Lee	rune@etri.re.kr
HP Inc.	Alan Berkema	alan-c.berkema@hp.com
Huawei Technologies, Ltd.	Miles Ma	maweidong@huawei.com
Intel Corporation	Richard Bardini	richard.a.bardini@intel.com
Intel Corporation	Michael McCool	michael.mccool@intel.com
Microsoft	Dave Thaler (by phone)	dthaler@microsoft.com
Qualcomm	Philip Hawkes	phawkes@qti.qualcomm.com
Samsung Electronics Co, Ltd.	Jin Choi	jinchoe@samsung.com
Samsung Electronics Co, Ltd.	Dwarkaprasad Dayama	dwarka.dayama@samsung.com
Samsung Electronics Co, Ltd.	Haeyoung Jun	haeyoung.jun@samsung.com
Samsung Electronics Co, Ltd.	Mark Trayer	m.trayer@samsung.com

 

IEFT:

ACKLIO	Alexander Pelov	alexander@ackl.io
Cisco Systems, Inc.	Steven Rich	srich@cisco.com
Ericsson	Ari Keränen	ari.keranen@ericsson.com
Ericsson	Göran Selander (by phone)	goran.selander@ericsson.com
Ericsson	Francesca Palombini	francesca.palombini@ericsson.com
Ericsson	Jaime Jimenez	jaime.jimenez@ericsson.com
Google	Thorsten Dahm	thorstendlux@google.com
Huawei Technologies	Spencer Dawkins (by phone)
Huawei German Research Center	Dirk Kutscher	dirk.kutscher@huawei.com
Philips	Oscar Garcia-Morchon	oscar.garcia@philips.com
Siemens AG	Matthias Kovatsch	matthias.kovatsch@siemens.com
Uni Bremen TZI	Klaus Hartke	hartke@tzi.org
Uni Bremen TZI	Carsten Bormann	cabo@tzi.org
vanderstok consultancy	Peter van der Stok	consultancy@vanderstok.org

 

Opening from Carsten. Presentation of IRTF, IPR, agenda: https://github.com/t2trg/2017-03-ocf/blob/master/slides/00-T2TRG-2016-03-ocf-intro.pdf

 

Presentation of IETF WG (high-level overview) and way to participate.

 

Ari presented IoT activities @ IETF: https://github.com/t2trg/2017-03-ocf/blob/master/slides/10-IoT_at_IETF_2017.pdf

 

Ari: Working groups (high-level overview of the mapping of the groups).

Ari: Diving into CoRE activities. CBOR WG presentation. 6LoWPAN presentation. 6TiSCH. LPWAN. ROLL. ACE. COSE. CWT. LWIG. T2TRG. IoT directorate. Collaboration with other groups, workshops, etc.

 

Mark Trayer, OCF Core Technology WG chair presented OCF & IoTivity

 

OCF do the specification work. IoTivity is funded by OCF but independent organization for implementing the OCF stack.

 

Alex: Are there parts of OCF not falling to IoTivity long term?

Thiago Macieira: guidelines say that anything in spec going beyond experimental MUST have open source.

Mark: to be certifiable must be in spec and open source

 

Mark presented OCF Areas of Technology development. Core Architecture, Security, Resource Models.

 

Currently only transport binding is CoAP. Maybe others in future. Re-using IETF standards.

 

OCF Client discovers devices, initiates interactions. OCF architecture REST based. Two roles per device: server and client. OCF device: coherent set of piece of information pertinent to a given property.

 

Physical platform:

/oic/p

OCF device:

/oic/d, /oic/res,

Example with modeling a lightbulb.

 

JSON Schema exposes resources, represented through CBOR, modeled with RAML.

 

On the wire everything is CBOR encoded. In the design, everything is designed with JSON.

 

Endpoint discovery with IANA registered OCF discovery URI (not same as in IETF CoRE). Endpoint discovery is CoAP Discovery. Multicast retrieve: /oic/res. Result is array of weblinks.

 

Collection of resources - array of web links (RFC 5988).

 

Vendor extensions are allowed. As long as it is not fundamental for the spec. No resources that are considered vertical-specific are defined.

 

Alex: will there be guidelines for vertical specific resources?

Mark: don't anticipate need for specific ones but security etc need to be addressed. Rich set of resource types and guidelines how to use them.

 

OCF bridge to work with other ecosystems. Semantic mapping to achieve this.

 

Matthias: Liaisons setup already?

Mark: huge sets. Semantic models etc. Not sure which are public already.

Matthias: liaisons including work on the bridges?

Mark: some do

 

All modeling is available at http://www.oneiota.org

 

Ari:  why currently deviate from some IETF specs?

Mark: Earlier few deviations, but now the intent is to take existing work instead of deviating.

 

Maybe changing the specs in the future evolution but will not deprecate things, like CoAP binding. Would hurt interop.

 

Security

 

Francesca presented Application layer security: https://github.com/t2trg/2017-03-ocf/blob/master/slides/31-Application-layer-security-protocols.pdf

 

Richard (on WebEx): what is “end-to-end security” for you? COSE uses the same end-points as OSCOAP. What are the differences?

 

Francesca: currently from CoAP-endpoint to another. Could also do later other protocols

Carsten: confusion probably comes from where you do encryption. With COSE token end-to-end is with instance and generates instance that verifies the token. We discussed end-to-end security 2,5 hours yesterday. Depends on the intermediaries. The work presented here focuses on CoAP intermediaries (proxies).

Göran Selander (from WebEx): on the slide on COSE; with COSE you would get across any application layer proxies. But would not protect the REST methods. That you can protect with OSCOAP.

Francesca: it's not simply COSE object from CoAP to HTTP endpoint; more thinking needed to cover all aspects

 

Philip: assume symmetric keys? (on OSCOAP slide 5)

Francesca: yes, keys in place

Carsten: but not only symmetric keys

 

??: what is in COSE encrypted packet header

Francesca: parameters for keys and replay protection

 

Philip: Option can be in clear or auth part. Does OSCOAP say which goes where?

Francesca: yes, we went through all options. Encrypt all options that can be, and left in clear the ones needed by proxies. For new options: should be encrypted unless meant to be changed by proxies etc.

 

Michael M: overhead in bytes and impact on max payload?

Francesca: coming later in slides

 

Options that are encrypted (in cipher text) removed from the outside.

 

Michael M: (on the overhead slide) if transmitting over CoAP channel and size of payload shrinks; overhead goes inside or outside?

Alex: reducing the CoAP payload in the sense of L2 payload getting “eaten up” by the OSCOAP option.

Michael: have to reduce max payload by this overhead?

Francesca: yes. And the current numbers are for optimization of OSCOAP coming soon

 

Dwarka D: What is the timeline for OSCOAP and how sure are you its end-to-end secure?

Francesca: for timeline, we just had plugtest. Waiting for WGLC of the draft after this. Draft is fairly simple and there are four open source implementations. Just adding small things in next update.

Carsten: have to update the CoRE WG milestones, but most interesting questions have been answered. Good to have implementation experience but pretty sure we can put lid on technical work by Prague IETF. Some interop before and at Prague. RFC mid next year. Technically stable middle of this year.

Matthias: you were confident enough to pick CoAP over TCP. This is same level of maturity. And just remember to keep dialog going on with IETF.

??: safe enough as long as we don't break backward compatibility. CoAP over TCP had less issues than security.

Carsten: need to just keep communication channels open

Dave (over webex): comment / feedback. Also editor of routing spec of OCF. True end-to-end, there are different semantics of REST/MQTT etc. endpoints. Want something like REST end to end. Seems OSCOAP could be REST end to end. Really hope IETF could work on REST end-to-end. Would work without DTLS.

Carsten: if you want end-to-end REST security, need to encode REST parts somehow. One way is CoAP

 

Philip: currently OSCOAP doesn't copy the auth data in the payload

Francesca: but it's delivered in the message

 

Francesca: In OSCOAP work lots of work on intermediaries. Wanted to keep forward proxy working with OSCOAP. OSCOAP has tight security association with client and server. That's not optimal for pub/sub or multicast. Multicast OSCOAP done to address that. Also defining defining use of COSE for pub/sub (OSCON). Submitting draft for Chicago IETF where pub/sub scenario is defined. Coming on Monday.

 

Carsten: used all time we have for security. Thorsten will talk how to get security of not being attacked by IoT devices. Need to consider how to secure Internet against threats from IoT devices. Activity at IETF OPS area looking at ways for devices to describe their behaviour.

 

Thorsten presented MUD: https://github.com/t2trg/2017-03-ocf/blob/master/slides/42-mud.pdf

 

Michael M: expected data rate and bandwidth usage included in descriptions?

Thorsten: not now. At the moment it's about reachability.

Alex: MUD is YANG model for constraints of firewall rules etc. Many things possible.

Thorsten: idea is that manufacturer does not need to write code and heavy lifting will be done by manufacturer. Device spits out URL to MUD file.

 

Matthias: discussed this yesterday how could be extended. For example working with smart phone to allow/not allow things.

Michael M: good to be able to be clear what is expected behavior. Can we give existing devices MUD files.

Dwarka D: How do you attach MUD file to device.

Thorsten: usually done for a class of devices.

 

RESTful Interaction

 

Carsten: Discussed in meeting last year what is our view on use of REST. Good that collection framework has been used at OCF. At research group looking into how we evolve our formats to be more hypermedia-driven.

 

Klaus presented REST and Hypermedia: https://github.com/t2trg/2017-03-ocf/blob/master/slides/43-coral-ocf-amsterdam-short.pdf

 

Different approaches to APIs, from versioning and tight coupling to using shared vocabulary.

 

Klaus: in OCF doing the more granular approach, right?

Mark: in OCF you can go to server and ask what it does

 

JinHyeock: for links and forms how to do this?

Klaus: links work as such and for forms needed something new. The CoRAL specification does the forms. Not fully established yet.

 

Mark: we have had lots of discussion around forms. Interesting to work with IETF: way we interact with resource we borrowed from CoRE interfaces (and went own way). Resource knows what interfaces it supports etc. Would like to at some point see where the CoRE interfaces is going where we have gone. Synch on that.

Klaus: nothing wrong with other approaches

Mark: we're now at point where just because you can doesn't mean you should. For interaction, would be interesting to be able to say more abstract than "I'm a lamp". How to efficiently define new queries and filters? What are the logical constructs that apply?

Matthias: CoRE interfaces at CoRE got stuck. The "view on resource" approach is fine. Nothing happening in CoRE that would be different. For forms, using RAML but not fully.

Mark: moving towards Swagger.

Matthias: form is a more generic thing than link. Link just has GET and no payload. That's info you can get from RAML. At WoT working on this too. Thing Descriptions. All groups use concepts of form.

JinHyeock: anything that can confuse, will. Good to be explicit on these.

Matthias: something that was started; no one is using "if", but OCF making use of it now

JinHyeock: have some challenges with if; hoping someone to do the heavy lifting to clarify

Mark: took it as good guidance how to do things. Michael K has been working on this.

 

Carsten: forms as a concept is good thing to take home. Draft in RFC editor queue called "Etch" for PATCH and FETCH. With FETCH can have filled-out-form in the payload. PATCH for updating parts of representation.

 

 

 

 

Mark: devices can be different places, in mesh etc. Not always easy to connect to them.  Practical things like multicast discovery gets swallowed by devices. Can we educate vendors so that it doesn't happen? Multicast discovery underspecified for CoAP (only should-level thing). Certain transports for CoAP like BLE not specified.

 

Dave T (WebEx): on the mesh, other thing IETF should talk about is use of multicast in constrained network could be inefficient. Hence things like RD. What is the right discovery mechanism?

Carsten: RD would have been my answer. Technology of IETF CoRE WG for this kind of questions is RD. For how to find RD there are different ways in draft. There's no the way to do that. Maybe good to look here if there's preferred way. We know how to find DNS server for big web. Maybe can use same mechanisms for finding RD (DHCP, RA, etc.).

 

Michael M: distributed RDs interesting. Now one RD has all data. What about if that was distributed.

Carsten: there is draft about that already. Research essentially. But could go that direction.

Michael M: might be more robust against attacks. What discovery mechanism scales nicely in the future.

Carsten: if anycast message is used, implementation of that can be distributed. From client PoV doesn't matter if it's single or many.

 

Mark: when multiple ways to do something, it's always challenge. Need guidance.

Michael M: what's the criteria picking the best way

Carsten: likely different for home and industrial

 

Carsten presented CoAP over TCP: https://github.com/t2trg/2017-03-ocf/blob/master/slides/52-CoAP-TCP.pdf

 

Michael M: why is the mandatory initial exchange with CSM?

Carsten: one endpoint may start to do things that don't make sense for the other. Better to have explicit exchange. Can be empty; that's fine.

 

Philip: signaling all sent on top of TLS?

Carsten: yes, all sent in bytestream that can be TCP, TLS, WebSockets

 

Dwarka D: Developers wanted to wait to have stable spec. No full fledged implementation on -07 revision of CoAP over TCP. Need to update from -04 to -07. Signaling did not exist in -04.

Carsten: will check off-line details of this

 

Carsten: there is no intention to change anything on this anymore unless there's strong message that something needs to be done. In next few days there will be submission to IESG to become an RFC. Area Director review, IESG review and RFC editor review phases left. RFC expected to be ready this year. RFC publishing process takes about 2 months. IESG review can happen quickly and can take few months.

 

Dwarka D: So draft -07 is almost RFC and no big changes expected? Will go to developers and ask them to implement that.

Carsten: Yes. And planning to call certain future draft versions of other drafts "implementation draft" that will not be changed unless strong feedback from implementers

 

Dwarka D: In OCF ongoing work / PoC for CoAP over BLE. Design proposed. Existing BLE has limitations since it's peer-to-peer. BLE packet format does not allow source and destination info. Created special header format that could go to BLE packet. CoAP traveling over BLE. Haven't received feedback from SIG. Since CoAP is done at the IETF, maybe such should be done at IETF instead of OCF.

Carsten: there's whole area of work about running CoAP over last mile. Recently wrote draft about CoAP over serial link. There is interest in the problem getting solved. Not replacement for running IP. But maybe want to e.g. use CoAP to setup IP.

 

Dwarka D: use case with wearables based in BLE. Communicate with smart phone for data. Maybe want to relay data to analysis. Taking CoAP makes easy to bridge to OCF ecosystem.

Carsten: BLE after packet size extension (change in spec)?

Dwarka D: yes.

Carsten: interested in collaborating. Would probably do in the RG for now.

Dwarka D: can ask project chairs to send it to IETF after sanitizing.

Mark: Dave T pointed out that for CoAP over anything we should talk to CoRE and T2TRG guys.

Dwarka D: connected to second presentation on e2e security. OSCOAP will get involved.

Carsten: OSCOAP would work already as such today

Michael M: any other CoAP over X? ZigBee? Z-wave?

Carsten: need to find people who are working on the boundary.

Mark: Need folks at the SIG to talk there. Have such at OCF but also need IETF folks involved.

 

Mark: we've seen commercial products where multicast used but well known issues in home networks for using that. What would industry have to do to make this work for grandmas.

Carsten: whole WG at IETF on DNS-SD. Also m-DNS. They have answers to some multicast questions. Resource Directory was designed to interface with mDNS.

 

Alan Berkema: unreliability in multicast, not ACKed. RFC on allowing turning multicast to unicast.

Carsten: can do something like multicast discovery on Bluetooth -- but that's weird. Would be good to have better answer. Basic idea: when join network, find RD, and talk to that.

Mark: issues such as scope of the discovery

Dwarka: IETF plans to talk to WFA to have CoAP packets Wi-Fi friendly? Some ports used by CoAP filtered on Wi-Fi multicast

 

Alex: roadmap for the time getting this answered?

Mark: ubiquitous connectivity longer term goal. Getting past APs more urgent.

Terminology

 

Carsten presented RFC 7228bis work https://github.com/t2trg/2017-03-ocf/blob/master/slides/62-RFC7228bis-terminology.pdf

 

When anyone detects discussion going off the rail because people use different terminology, we would like to know this and document terms.

 

Michael M: what is also important for classification is hardware protection. TrustZone, etc.

Mark: had very similar discussion last meeting. Trying to identify target devices for OCF devices. Class 2 seemed reasonable but whole bunch of other features than memory relevant. Security guys especially had features in mind. Hardware acceleration etc. Security usually the most computationally expensive.

Michael M: good to have modifiers. "Class M with hardware security".

Mark: Strategy WG at OCF had discussion on this. Could bring here. There are meeting minutes somewhere

Michael M: main issue was that we don't know if device has enough resource to "do security"

Carsten: depends lot on algorithms. Had one discussion about this in firmware update space.

Michael M: often can just do long enough computation.

Carsten: for firmware 10 minute OK, for "light switch on" not.

Michael M: could pick benchmark and threshold to fit to certain class.

Steve: also entropy is important

Carsten: yes

 

Mark: seems we are fairly well aligned. RESTful and all. But terms like interface, signal, etc. are challenging.

Carsten: draft on RESTful design has definitions for RESTful design terms

 

Ari: should check the RESTful design draft. Will send you link to this.

Mark: also design patterns

Alex: common document to document these issues is useful

Michael M: design patterns leads to ontologies

 

Carsten: good if can dig out the old minutes and share requirements

 

Wouter: how to communicate with IETF? Always through members?

Carsten: just send message to the mailing list

Michael M: can use Github issues too?

Carsten: sure, but trying to keep technical discussion on the list

 

JinHyeock presented RESTful interaction OCF view: https://github.com/t2trg/2017-03-ocf/blob/master/slides/63-OCF-REST.pdf

 

Resource types defined in different ways. IPSO uses one and OneM2M other way. OCF developed own way.

 

Michael M: notifications with HTTP issues arise; more than one way to do this.

JinHyeock: for example OneM2M uses create message for this

Peter VdS: don't mention multicast. Notification seems unicast only?

JinHyeock: some use cases that would need multicast in consideration

 

Ambiguities with POST. Happy to use PATCH instead.

 

Michael M: with pub/sub design pattern what's good way to map "named topics" to protocols without named topics?

Mark: can take CoAP Pub/Sub broker from IETF

Jaime: topics usually come from resource but can be arbitrary

Michael M: no obvious mapping that is not multi-valued

 

Mark: looking at complexity; idea in heads is using lego blocks. Putting resources together to collections. And collections of collections. And concepts of scenes. Can "talk to scene and stuff happens".

 

Need more minute resource manipulation.

 

Michael M: anyone looking into time synchronization with CoAP?

Carsten: writing related draft right now

 

Matthias: quite a list of questions for input. Will take these to address in RESTful design draft.

Carsten: please send us more of these kind of presentations

 

Matthias: talked about resources and properties. What is current working assumption? Complex resources with multiple resources?

Mark: both; resource can be in more than one collections or complex resources.

Michael M: formal data model for OCF for resources?

Mark: recommendations. Bunch of lego blocks.

 

Summary and next steps

 

Carsten: We have several action items on sharing information. When do we do the next meeting of this kind? Should we do more often?

Mark: OCF November meeting in Singapore. Back-to-back with IETF meeting. Trying to have choices of cities that make sense for co-location.

Carsten: establishing more communication channels that respect the OCF rules (T2TRG has very few rules). Also could do focused web meetings on specific topics. Topic of forms came up. Issue of discovery. Who would be the right person as contact point from OCF?

Mark: me and Wouter (tech community chair).

Wouter: the higher guy of the team. Data modeling is Jon's work. Architecture guys went home already.

Mark: Philip also security person.

Wouter: OSCOAP interesting and will add to security work.

Matthias: Resource Directory came up. OCF uses same mechanism but different URI. Something similar in WoT. Who should we talk to?

Wouter: to Mark

Mark: anything related to RD and multicast talk to me

Jaime: looking for more people working on RD

Matthias: my proposal last year was that RD draft would allow other than CoRE link format. OCF format uses web links. TD something similar.

Peter VdS: this functionality is in already

Wouter: good to have session on specs that are almost finished and that we can use

Carsten: Would like to get input in IETF WGLCs. Should setup regular channel where we make sure WGLCs are seen by OCF.

Wouter: need probably more than two weeks due to overhead time

Carsten: don't need official OCF position

Mark: good idea; currently rely on OCF individuals at IETF

Alex: nice to have tighter coupling of discussions. What's frequency of OCF meetings?

Mark: on phone weekly. Sometimes twice. Sometimes one every two weeks.

Wouter: need paid membership to participate.

Matthias: for universities very hard to pay. For example ETH's president would need to sign.

Wouter: probably can do something about that. Individuals can join too. But don't want individual members from companies on that. Can talk to OCF membership people to make possible e.g. department of professor to join.

Alex: weekly calls sounds high load. But when certain topics discussed, could involve authors of IETF work etc

Wouter: will write e-mail on this

Mark: Github repo for sharing and issues there

Matthias: way to follow pieces of work (e.g., RD at CoRE) would be useful. Like notifications from editors. Adds load for them, but usually they are interested in feedback.

 

Dave T: summary of next steps. Next step for (#1 in list) OSCOAP covered already. How about: 2) CoAP over Bluetooth 3) Changes to TCP-TLS from -04 to -07 and IoTivity 4) multicast relay delay 5) improvements to RD discovery

 

Mark: for BLE working with SIG group chair. Will share via Ari etc. TCP-TLS internal to OCF. Multicast issues and challenges to be worked at T2TRG and CoRE and do requirements draft work.

 

Michael: Next meeting at Singapore.

Dave: Nov 11th the Saturday between OCF and IETF meetings.

Matthias: 6-10th there's WoT meeting in California. And lose two days in travel from California to Singapore.

Alex: T2TRG meeting also in Prague?

Carsten: will meet with W3C week before Prague in July. Prague IETF in July. Next T2TRG last week of September with open source people from RIOT and ICN communities.

JinHyeock: OCF meeting in Krakow around that time.

Matthias: T2TRG meeting in Prague/Dusseldorf. Is Prague is better, good to have input from this group.

(discussing who coming to Prague meeting on July)

 

Carsten: very useful meeting. Let's do this again.

 

(meeting adjourned)

 

Action Item Summary:

• Provide an overview of OCF’s interfaces guidance to IETF for review. – Mark Trayer

• Consider enhancing the guidance on Resource Directory discovery mechanisms for multicast and distributed networks. – IETF

• Send to IETF the BLE-GATT Project overview after removing any member-confidential information. – Mark Trayer / Dwarka Dayama

• Ask IoTivity to implement the current 0.7 IETF CoAP/TCP spec with the CSM change and provide feedback to IETF. – Dwarka Dayama

• Send the list of items from the September 2016 OCF Taipei meeting to IETF for their guidance and recommendations (e.g. scope, multicast discovery, resource directory, etc.). – Mark Trayer

• Share information with IETF on the IoTivity overhead analysis. – Mark Trayer

• Send to Mark Trayer the glossary of RESTful design terminology. – Ari Keränen

• Send to IETF the draft OCF roadmap, priority items and requirements, and design pattern requests/suggestions. – Mark Trayer

• Send to IETF the OCF’s RESTful architecture slide deck outlining the list of requested terminology and definitions for alignment. – Jin Choi

• Review OCF’s data models in the public www.oneIoTa.org site. – IETF

• Forward to OCF any relevant ‘last call’ emails for feedback on draft IETF specs. – Carsten Bormann

• Coordinate logistics for the next joint OCF/IETF face-to-face on November 11 in Singapore. – Mark Trayer / Ari Keränen