Agenda

<ryuichi> https://www.w3.org/WoT/IG/wiki/PlugFest_WebConf

<ryuichi> agenda

kaz: agenda should include
... Matsukura's update, Koster's input, McCool's update
... physical requirements and possible scenarios

Matsukura's update

<ryuichi> https://github.com/mryuichi/documents

matsu: shows slides
... would like to see the information here is correct
... starting with Panasonic
... Siemens
... Lemonbeat
... Intel

mccool: details in my presentation

kaz: so you'd like to clarify which servient from Intel will get connected here

matsu: yes

mccool: using SSH tunnel
... not really specialized proxy
... proxy and tunnel

matsu: would like to clarify which servient can speak the WoT interface

mccool: I have OCF devices
... all those devices talk CoAP
... they're WoT devices because they use TD

kaz: so we should clarify which servient exposes their capability how
... e.g., exposeThing

matsu: which device from Intel can be connected here?
... what is the protocol for the OCF devices?
... want to clarify which part of your servients would talk with the others' servients

koster: agree
... would add a point for interoperability
... not all the servients have the capability of consuming, e.g., OCF devices
... we really have to see the orchestration
... planning to do that on proxies
... adapt to every protocol

mccool: points of connection
... you can talk to devices using their consuming protocols

koster: just function as gateway
... added local application servient by node-red to this diagram based on Koster's input
... next [Servients and protocols (1 of 2)]
... Lemonbeat by Uday
... next [Servients and protocols (2 of 2)]
... Intel and SmartThings
... Fujitsu's application can run on either the remote/local side

mccool: local link vs global link
... global URL goes through the remote proxy
... my plan is both of them in the TD
... and try the local link first
... local links wont' work outside

matsu: this time there is no remote device servient?

mccool: motion sensor, camera, etc.

koster: endpoint app
... happen on the cloud
... remote device servient
... expose REST api there
... we can call that a remote device servient
... how to make the protocol binding
... doesn't require a bridge
... could be done by software adaption

mccool: my suggestion is definition based on the architecture document
... definition could be operational
... we can add additional protocols

koster: SmartThings API is REST API

mccool: note that we avoided using "servient" in many places
... a lot devices can expose their capability

kaz: we should see Koster's proposal and McCool's proposal
... and think which part could be connected which servient from Matsukura's diagram

koster: remote proxy and local proxy are connecting points

matsu: Panasonic's device servient can be connected with the other's servient?

yama: please show the table (1 of 2)
... some update
... left column is only HTTPS
... right column is HTTPS+WSS

mccool: will bring Amazon Alexa
... maybe it will be confused given Panasonic also will bring their Alexa
... can change the command, though
... we can discuss it during PlugFest
... do you use Home Skill?

kawa: only custom skill

mccool: can do either way

uday: please show Lemonbeat
... not water valve but binary actuator

mccool: possible scenario...

kaz: which servient do you want to get connected?

uday: any ones

kaz: will you provide local proxy as well?

uday: no...

matsu: but local gateway might be a local proxy?

uday: ah, yes

mccool: will use SSH traverse for AVS

koster: websocket works with SSH tunneling. right?

mccool: you can tunnel the protocol through

matsu: which part from your system would be connected as a servient?

McCool's update

[@@@updated slides tbd@@@]

mccool: shows his updated slides
... explains his setup
... [1.5 Metadata Bridging]
... can use other specialized solution
... this framework includes just standard setting
...

koster: local one vs global one
... there are 2 resource directory
... the global thing can be reachable from the local side
... but...

mccool: you want to use local things available
... maybe orthogonal issue from proxy

matsu: there are a lot of issues unresolved
... after the upcoming PlugFest, we need to clarify them

kaz: so we should ask McCool to think about which part from McCool's diagram could be connected with which part from Matsukura's diagram

mccool: WoT-aware proxy and WoT-transparent proxy
... not useful to worry too much about NAT

koster: possibly one separate proxy which pipes the other

matsu: what about Koster's proposal?

Koster's configuration

Koster's slides

koster: [Configuration]
... ST could, Om2m, Remote Gateway, App Droplet
... router
... Lan
... ST Hub, MQTT Sensor, IKEA Hub, OCF Bridge, Local WoT Gateway, Local WoT App
... MQTT, OCF, LWM2M, HTTP, HTTP/WS
... [Configuration - OCF IKEA Bridge]
... who finds what?
... everything could be described using TD
... update periodically
... [Configuration - SmartThings]
... SSH tunnel between ST Cloud and ST Hub
... remote proxy (gateway) - local proxy (gateway) - local WoT App
... [All Configurations]
... my view for plugfests

mccool: IETF collocated with OCF
... OCF Melaga, Spain
... one of the possible places for WoT
... let's have discussion during TPAC

koster: TDTRG?
... interoperability with others would be good

uday: interoperability between IKEA hub and OCF bridge?

koster: node iotivity on rhaspvery pi
... just doing easy way to expose to OCF

uday: not semantically interoperable

(some more discussion)

kaz: Koster, are you aware which part of your diagram to be connected which part of Matsukura's diagram?

koster: yes
... local gateway is local proxy
... remote gateway is remote proxy
... apps consuming proxy
... IKEA hug has OCF bridge for local WoT proxy

matsu: thanks
... will update my diagram
... any other topics for today?

mccool: schedule?
... local/remote directory?

kaz: we can have another call on Nov. 1
... but do we need another call before that?

mccool: we can have discussion at TPAC as well

uday: fyi, Tue/Wed are holidays here

mccool: next week have to work on implementation

daniel: based on the FPWD

mccool: can call in next week

[adjourned]