AP+DI (Room 153) -- 28 Jan 2016

9am-10am: TF Breakout - AP+DI - Work Item Discussion

WG item proposals

<kaz> soumya: work items for the WG

<kaz> WG item proposals

<kaz> soumya: starting with "Uniform and Technology Independent Discovery"

<kaz> ... common mechanism for various physical devices, e.g., radio

<kaz> ... would be useful to have information as metadata

<kaz> johannes: regarding the proposal here

<kaz> ... most relevant topic is "Web of Things scripting API" and "Bindings to Common Protocols"

<kaz> ... (goes through "Web of THings scripting API")

<kaz> ... any comments at the moment?

<kaz> ... deriverable for WG?

<kaz> ... in scope or out of scope?

<kaz> ... (goes to "Bindings to Common Protocols")

<kaz> ... two comments already

<kaz> dsr: shown layered diagram

<kaz> ... we can define abstraction layer for things with abstract messages etc.

<kaz> ... how to map specific protocols

<kaz> ... collaboration with IETF CoRE WG, etc.

<kaz> johannes: we have a common picture

<kaz> ... collaboration with IETF and other SDOs

<kaz> dsr: WebSocket protocols is done by IETF

<kaz> ... while WebSocket API is done by W3C

<kaz> johannes: minimum requirements for binding

<kaz> ... there would be assumptions, guidelines

<kaz> ... starting with HTTP and CoAP

<kaz> dsr: also need for testing environment

<kaz> ... testing framework

<kaz> ... to guarantee interoperability

<kaz> johannes: test framework means script on one side and...?

<kaz> dsr: test suite for checking features

<Soumya> HTTP protocol binding - http://www.onem2m.org/images/files/deliverables/TS-0009-HTTP_Protocol_Binding-V1_0_1.pdf

<kaz> johannes: includes a reference implementation?

<Soumya> MQTT protocol binding - http://www.onem2m.org/images/files/deliverables/TS-0010-MQTT_protocol_binding-V1_0_1.pdf

<kaz> ... some kind of compliance test?

<kaz> dsr: W3C doesn't do compliance test itself

<kaz> ... tests and test suite approved by WG

<kaz> joerg: tests include abstract layer?

<kaz> dsr: yes

<kaz> (going back to the discussion on "protocol binding")

<kaz> soumya: put URLs on the IRC

<kaz> ... Overview of HTTP Binding

<kaz> ... (OneM2M spec)

<dsr> The W3C Working Group would define a suite of tests for normative statements in the Candidate Recommendation, and would be at the abstraction layer the WG is defining, i.e. the “things” layer.

<kaz> let's talk about that as a separate topic later in detail

<kaz> soumya: MQTT Binding

<kaz> johannes: reference architecture and guidelines

<kaz> ... would push it on the Github

<kaz> soumya: (visits the Github repo)

<kaz> WoT repo

<kaz> johannes: under the WG sub directory

<dom> Web of Things scripting API

<kaz> johannes: what is the actual target to be done by the WG?

<kaz> ... (goes through the list of "Scope")

<kaz> ... API definitions

<kaz> ... Define callback signatures

<kaz> ... Security model and policies

<kaz> ... concept of applications spanning multiple things... might be an appendix

<kaz> ... TD interactions as manifest

<kaz> ... (next "Out-of scope")

<kaz> ... solutions for particular runtimes/frameworks

<kaz> ... middlewares and protocol drivers

<kaz> ... (Deliverables)

<kaz> dsr: when it comes to language independent definition

<kaz> ... still need mapping to languages

<kaz> johannes: that is the case with our implementation

<kaz> ... but still could do discussion as a standard work

<kaz> ... it would be good to have discussions

<kaz> ... (goes to the next section, "Bindings To Common Protocols")

<kaz> ... if I'm an implementer, how to implement the binding mechanism?

<kaz> ... actual protocol definitions are out of scope

<kaz> dsr: "resource model and URI concepts" would be too strong assumption

<kaz> ... we're not talking about concrete protocols but abstract model

<kaz> ... abstract data model and abstract messaging mechanism

<kaz> ... small set of things

<kaz> dsr: we have CSS, XPath, etc., as well

<kaz> johannes: may consider mapping between XPath and URI

<kaz> dsr: in the abstraction layer, we don't care about that

<kaz> johannes: in that case, what would be the moderate target?

<kaz> dsr: why do you need to?

<kaz> ... how to map the abstraction model is the key

<kaz> ... using URI implies schema

<kaz> johannes: we want to provide guidelines

<kaz> ... MQTT, BLE could be mapped to URIs

<kaz> dsr: each programming language has its own mechanism

<kaz> johannes: we still need to provide how to map each protocol

<kaz> ... using some uniform way to specify resources

<kaz> claes: a bit confused by this discussion...

<kaz> ... there are more than one ways

<kaz> johannes: if you want to use bluetooth, we need to map it to web mechanism for web browser

<kaz> ... URI is used for that

<kaz> ... when I have a property, how to use that property?

<kaz> dsr: in JavaScript that is an object

<kaz> dape: you still want to know the URI for communication, don't you?

<kaz> (some more discussions)

<kaz> kaz: is it ok by you, Dave, if we handle "Resource Model" topic and "URI concept" separately?

<kaz> dsr: yes, we should handle them separately

<kaz> (some more discussions)

<kaz> joerg: we should do the detailed discussion on this later

<kaz> everybody: agrees

<kaz> soumya: (goes back to the WG item proposal wiki)

<kaz> joerg: recognize different categories?

<kaz> soumya: could be a work item

<kaz> joerg: would assume the same model as protocol mapping

<kaz> johannes: we had discussion yesterday, and don't think there is anything missing

<kaz> soumya: if no further comments, would finish this session

<kaz> dsr: can easily find our way to the github page from the Task Force wiki

<kaz> soumya: (goes back to the agenda wiki)

<kaz> ... TD+DI (room 151)

<kaz> ... AP+SP (room 153)

<kaz> [ break ]

<scribe> scribe: tidoust

Provisioning

Soumya: Objective of this last session is to discuss provisioning that we haven't had time to touch upon yet, and discuss next steps.
... For provisioning, I wanted to give a brief overview of OMA LwM2M
... It defines an application layer protocol, between client and server for constrained devices.
... Toward that goal, it provides several interfaces
... One of them is the Bootstrap, but also the registration and device management interfaces.
... Not planning to review all of them here.
... About the bootstrap, the goal is to provision essential information into the LwM2M client.
... Four supported modes (see slide)

[looking at the specification]

Mohammed: I may explain. This is based on what we have in OMA.
... The factory bootstrap is when the device already knows where to connect because it has all the information needed.
... The second mode is the SIM card model. The SIM card connects to any network and retrieves the provisioning information from the right operator.
... The Client initiated bootstrap requests a user action to generate the bootstrapping. It can be from an app or whatever. Example of the setup button on the gateway.
... Last one is server initiated where the server needs to send updates to a particular device.

Soumya: Thanks. This covers provisioning. It may be useful to have secure provisioning.
... We all understand why it's necessary, it would be good to scope it properly.

Mohammed: The main thing is to identify which device is connected to the server. The bootstrap is the main step. After that, you can do whatever you want.
... It benefits the server and the client.

Soumya: One open question, let's say you have a mobile server, anybody can attach to your server. How do you trust the exchanges?

Mohammed: All defined in the protocol.

[Mohammed explains the different steps of the bootstrapping in the case of mobiles. The URI of the server to which the client will send the request is constructed out of the parameters and identifiers contained in the SIM card. No authentication needed]

Francois: Cannot the URI be faked?

Mohammed: It can, but this is just about receiving a small set of information that is not that sensitive and with which you cannot do much without further authentication.

Rui: Free does it all automatically, server-initiated bootstrap.

Mohammed: Server-initiated is typically used in roaming. The "welcome" message you get is an illustration of it.
... Establishing the client-server communication is the most important part.

Francois: Looking at it from the application layer perspective, what would we need to expose?

Soumya: Right.
... It has to be part to the scripting API, I guess.
... This part would be the setup part in the setup/operation parts we mentioned yesterday.

Francois: What is the relationship between registration and provisioning?

Soumya: First point, during provisioning, you get the URI to which you will upload your thing description.

Mohammed: It may be viewed as a special case of registration, perhaps.
... The server gives you a lot of information about what you can do.
... A difference is that a provisioning server listens to you specifically. The registration server listens to devices on a particular network or area.

Soumya: If you consider thing-to-thing perspective. Maybe during provisioning, you understand that there may be a thing you connect to. That could be part of the setup operation.

Mohammed: One thing that should be in scope is what kind of management you want to have on a thing? Do I need to restart, pause, reset a thing?
... As server, I need to do this device management actions. Important from a provisioning perspective.
... Usually, the server defines the different management functions.

Soumya: Do you know about other technologies that we can look into on top of OMA?
... I tried to look into Nest for instance. The setup is complicated. You have to attach it to your Wifi, etc.

Mohammed: Nest is proprietary. Another spec to look at maybe could be BBF TR-069

<Soumya> BBF TR-069 - https://www.broadband-forum.org/technical/download/TR-069.pdf

Mohammed: It would be interesting to see how they do the provisioning and other functions.

Francois: As part of the setup operation, many devices, e.g. Chromecast, start in a mode where they create an ad-hoc Wifi network that the user connects to to pass the Wifi credentials. Is it part of provisioning?

Mohammed: Yes, to some extent. The configuration parameters should be part of the provisioning response.

Soumya: The goal is to come up with a definition of what provisioning is, as we did with discovery. In terms of the group, discovery gives you a thing description.
... [showing the related WoT IG wiki page on provisioning]
... One thing that I noticed is that there are ways to include security aspects to provisioning.

Mohammed: I would suggest putting these definitions in a central place.

Francois: Hopefully, the IG deliverable will merge these definitions in a Terminology section.

<mdadas_> OMA LwM2M DevKit : https://github.com/OpenMobileAlliance/OMA-LWM2M-DevKit

Francois: Taking the analogy of Internet Connection, provisioning is like DHCP or user may enter manual settings. In that sense, provisioning is what allows you to get the parameters you need to switch to proper operation mode.

Next steps

Soumya: I will work on the transition of the Tech Landscape survey to GitHub.
... One thing to emphasize is that now is the right time to have joint description, e.g. with Sebastian on thing descriptions to create filters for discovery
... Of course, bindings to protocols is important. We need to have a way to give that information to the AP task force.

Francois: I agree with the general description. Now it may be time to merge all task forces back into the IG to ensure that everyone converges on a similar vision, and that the IG is able to extract a concrete list of technical gaps.

[breakout adjourned]

- DRAFT -

AP+DI (Room 153)

28 Jan 2016

Attendees

Contents

9am-10am: TF Breakout - AP+DI - Work Item Discussion

WG item proposals

Provisioning

Next steps

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output