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

[PlugFest] 11 October 2017

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 13 Oct 2017 02:51:54 +0900
Message-ID: <CAJ8iq9Xi5nLSkiuN=8CeijF4LjenZ=mNf6ONGZBTc5oXbNrSmQ@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.

Please note that we'll change the time of the PlugFest call to
"after the main call (=9am US Eastern)" instead of "before the
main call (=7am US Eastern)" to make it fit US Pacific participants





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

                               - DRAFT -

                              WoT PlugFest

11 Oct 2017

   See also: [2]IRC log

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


          Kaz_Ashimura, Michael_Koster, Matthias_Kovatsch,
          Christian_Glomb, Michael_McCool, Ryuichi_Matsukura,
          Takeshi_Sano, Uday_Davuluru, Zoltan_Kis,
          Daniel_Peintner, Kazuaki_Nimura, Tomoaki_Mizushima,
          Masato_Ohura, Toru_Kawaguchi





     * [3]Topics
         1. [4]time slot for this call
         2. [5]PlugFest plan - Matsukura-san
         3. [6]Intel's plan
     * [7]Summary of Action Items
     * [8]Summary of Resolutions


      [9] https://github.com/w3c/wot

   <McCool> should create a directory under
   [10]https://github.com/w3c/wot/tree/master/plugfest for
   2017-burlingame plugfest

     [10] https://github.com/w3c/wot/tree/master/plugfest

time slot for this call

   kaz: ok to change the time after the main call?
   ... any objections?


   kaz: will change the reservation

PlugFest plan - Matsukura-san

   [11]Matsukura-san's slides

     [11] https://lists.w3.org/Archives/Public/public-wot-ig/2017Oct/att-0010/Servients_TPAC2017_171011b.pptx

   matsu: 4-layer structure for PlugFest
   ... 4 layered servients: app, remote proxy, local proxy and
   ... [Servients and protocols]
   ... generated a table on servients and protocols
   ... filled in with Fujitsu and Panasonic
   ... Application Servient, Remote proxy Servient, Local proxy
   Servient, Device Servient
   ... and interface protocols between them
   ... (goes through the table)
   ... (explains Fujitsu's example)
   ... air conditioner, LED and blind connected with http
   ... also another LED connected with HTTP
   ... can update the table if you can provide the information

   mccool: similar table on the f2f wiki?
   ... which protocol on which side?

   [12]F2F wiki

     [12] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_4-10_November_2017,_Burlingame,_CA,_USA#PlugFest_.284-5_Nov_2017.29

   matsu: if you support more than 1 protocol, please say so

   mccool: question on the first page
   ... [Servients from participants on TPAC 2017 plugfest]
   ... local proxy inside or outside of the local net?

   koster: same question
   ... can also have some slide on that
   ... protocols could optimize the connection

   matsu: (moves the line of "NAT/Firewall" above the "Local Proxy

   kaz: think that was a bug

   matthias: similar setup to Japan?

   kaz: do we really want to have 6 apps?

   mccool: maybe interesting

   koster: maybe everybody don't need to provide end-to-end system
   ... multiple applications are good for WoT
   ... for example, my application can connect with multiple
   ... that is a story we need

   kaz: +1

   mccool: do you want to finish this first?

   matsu: yes (and move ahead)
   ... [High-level description of Issues]
   ... Fujitsu has identified potential issues
   ... also would like to hear your about your issues
   ... [Deadlines and plugfest schedule]
   ... (strawman idea on the schedule)
   ... Oct. 18: complete the table of "servient and protocol"
   ... who provide what?
   ... collection of TD for the servients for the plugfest
   ... clarify the application scenarios
   ... Oct. 25: specify inter-servient interface
   ... Nov. 4-5: Fujitsu open at 9am-6pm
   ... 1st day (Nov. 4): prep and plugrest
   ... 2nd day: plugfest in the morning
   ... demo and discussion in the afternoon

   kaz: the scneario is something like Koster mentioned?

   matsu: yes

   matthias: tx
   ... please put this as well on the plugfest repo

   mccool: suggests:

     [13] https://github.com/w3c/wot/tree/master/plugfest

   <mkovatsc> (more specifically)
   game (does not exist yet)

     [14] https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame

Intel's plan

   mccool: added information to the f2f wiki table

   [15]F2F wiki

     [15] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_4-10_November_2017,_Burlingame,_CA,_USA#PlugFest_.284-5_Nov_2017.29

   slides to be added under

     [16] https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame

   mccool: (goes through the slides)
   ... alexa for voice interaction
   ... also PoC slides
   ... [Web of Things Roadmap - SHort Term]
   ... [Metadata Bridge]
   ... what we did
   ... read external metadata and translate into Wot TDs
   ... [Metada Bridge: Phase 1]
   ... many copies of leaf processor
   ... OCF HTTP bridge and OCF metadata bridge
   ... translate into TD
   ... (on the Gateway side)
   ... [Metadata Bridge: Phase 2]
   ... for Burlingame
   ... still have a meta data bridge
   ... traversal via NAT
   ... WoT Shadow Servient
   ... and Web Dashboard
   ... also would use Thing directory
   ... cloud is actually on my pc in this version
   ... update my metadata as RAML
   ... that's my minimum requirements
   ... [Voice Control]
   ... [Voice Control Burlingame WoT Plugfest, July 2017]
   ... impement Alexa Skill
   ... voice commands to actual skills
   ... back to the shadow servients
   ... Alexa Skill reads Thing directory
   ... local IoT devices superimposed
   ... that's I'm planning to do
   ... [Fog Integration]
   ... also thinking about this
   ... I have a proximity detector
   ... walking through a camera
   ... application I want to run
   ... make services discoverable and locally available
   ... would like to make CoAP working

   kaz: connectivity with the Fujitsu proxy?

   mccool: local proxy has upstream and downstream
   ... not really clear about DS, AS, PS, etc.
   ... wondering we should add hyperlink for the detail of each
   ... URI for each device
   ... need to clean this up

   koster: how to add information to the table

   mccool: can work on the proxy side myself as well
   ... we need to take the information instead
   ... also wondering if we can make an effort to get tickets
   ... for encryption

   kaz: Matsukura-san, do you think Fujitsu also can try secure
   ... if we can clarify the interface between Fujitsu proxy and
   Intel proxy, maybe those 2 pieces could be connected with each

   matsu: should I add HTTPS as the protocol?

   mccool: possible
   ... let's talk about that later
   ... some of the scenario I'm thinking

   koster: common capability for those?

   mccool: I have some particular scenario in my mind

   kaz: we need to clarify possible scenarios from all the
   participants' viewpoint
   ... also wondering what kind of information is needed for the

   <mkovatsc> [17]http://plugfest.thingweb.io/

     [17] http://plugfest.thingweb.io/

   mccool: starting with adding a column?

   matsu: device servient for OCF device

   mccool: WoT Proxy for HTTP
   ... don't want to have different protocols for WoT devices
   ... even though we need additional one for OCF devices

   matsu: expose Thing and consume Thing
   ... your devices are expose Things?

   mccool: WoT proxy translate HTTP into CoAP
   ... might create a shadow servient which expose the capability
   using HTTP
   ... still consider these devices are participants of WoT
   ... we need concrete definition, though
   ... local proxy, remote proxy, shadow servient, Thing
   directory, etc.

   matsu: I think we'd like to concentrate on inter-Servient
   interface for the upcoming PlugFest
   ... so this might be out of scope?

   mccool: we can have terms on what we mean

   kaz: think this is similar to Panasonic's setting
   ... McCool can expose the proxy servient which is connected to
   OCF devices

   mccool: or the local proxy could be called as "OCF HTTP/CoAP

   matsu: the structure is similar to Pansonic's mechanism
   ... they have a translater between HTTP and Echonet on the
   local gateway side

   mccool: agree
   ... logical way for OCF Things
   ... will upload this presentation on GitHub
   ... also would like to talk about the roadmap in long run
   ... incubation, WD, candidate, final

   matthias: question on [Metadata Bridge: Phase 2]
   ... one of the questions Matsukura-san made
   ... on synchronization
   ... how this connection between servients looks like?
   ... with proxy servient from Fujitsu, Panasonic or Siemens

   koster: exposed Thing is servient

   matthias: what is the existing connection?

   mccool: create 2 devices

   koster: how to open the tunnel?
   ... which pattern you choose?

   matthias: one of the main challenges
   ... different parties bringing different mechanisms

   matsu: ok

   koster: shadow servient goes through the NAT
   ... other servient talk with Thing directory?

   matthias: you can't go through the NAT

   mccool: the outside can't see the inside
   ... shadow servient can get information from Thing Directory
   but can't go back to the local side
   ... Pansonic may have some solution

   kaz: we should document that issue as well
   ... maybe better to have an HTML or might be MD instead of PPT

   koster: MQTT is another one
   ... this is good to start the discussion

   mccool: the time is another issue...

   koster: trying different mechanisms is good (for PlugFest)

   matthias: Matsukura-san's initial expectation
   ... everyone can get on the same page
   ... but we already got interoperability issues
   ... put a link before

   <mkovatsc> [18]http://plugfest.thingweb.io:8081/api.json

     [18] http://plugfest.thingweb.io:8081/api.json

   <mkovatsc> [19]http://plugfest.thingweb.io:8081/td

     [19] http://plugfest.thingweb.io:8081/td

   koster: people have different ways for NAT

   mccool: you can't register URI behind NAT
   ... that's one of the reasons we need shadow
   ... should we continue the discussion?

   kaz: we should put issues on GitHub and continue the discussion
   next week

   matthias: Matsukura-san should put the issues on MD
   ... and slides on the GitHub PlugFest area

   mccool: and the table should go into the wiki

   matthias: editing table on wiki is pain :)

   mccool: ah, PPT is fine in that case :)


Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [20]scribe.perl version
    1.152 ([21]CVS log)
    $Date: 2017/10/12 17:44:17 $

     [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [21] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 12 October 2017 17:53:04 UTC

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