W3C home > Mailing lists > Public > public-wot-ig@w3.org > October 2017

[PlugFest] minutes - 25 October 2017

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 26 Oct 2017 00:24:32 +0900
Message-ID: <CAJ8iq9VKR+h0JVuvoYM4aZzwEBHeE+BZv5NNJMh77K=kXp7xcg@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:

also as text below.





      [1] http://www.w3.org/

                               - DRAFT -

                              WoT PlugFest

25 Oct 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/10/25-wot-pf-irc


          Kaz_Ashimura, Kunihiko_Toumura, Michael_McCool,
          Ryuichi_Matsukura, Takeshi_Sano, Taki_Kamiya,
          Toru_Kawaguchi, Dainel_Peintner, Uday_Davuluru,
          Tomoaki_Mizushima, Michael_Koster, Kazuaki_Nimura,
          Masato_Ohura, Takeshi_Yamada, Keiichi_Tokuyama




     * [3]Topics
         1. [4]Agenda
         2. [5]Matsukura's update
         3. [6]McCool's update
         4. [7]Koster's configuration
     * [8]Summary of Action Items
     * [9]Summary of Resolutions


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

     [10] 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> [11]https://github.com/mryuichi/documents

     [11] 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

   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

   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
   ... 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

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

   [12]Koster's slides

     [12] https://lists.w3.org/Archives/Public/public-wot-ig/2017Oct/att-0028/wot-plugfest.pptx

   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
   ... [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
   ... [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


Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [13]scribe.perl version
    1.152 ([14]CVS log)
    $Date: 2017/10/25 15:24:08 $

     [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [14] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 25 October 2017 15:25:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:19 UTC