See also: IRC log
<scribe> scribenick: kaz_
Registration site (for TPAC/PlugFest attendees):
* https://www.w3.org/2002/09/wbs/1/WoTPlugFest201711/
* https://www.w3.org/2002/09/wbs/35125/TPAC2017/
matsu: updated the slide based on the
information on the f2f wiki
... you can see there are 5 colors
... application servient, remote proxy servient, local proxy
servient, device servient and devices
... the left most row is Panasonic
... the second row is Siemens
... then Lemonbeat, Intel, SmartThing, Eurecom
... will get concrete information on Eurecom from Soumya
soumya: next week
matsu: the right most row is
Fujitsu
... Nimura and myself
... also Mizushima-san from IRI will provide an application
servient
mccool: sorry have not put info on the
wiki yet
... would provide various devices
... not device servient itself but
device servient generator
matsu: application as well?
mccool: yes
... using Alexa
... web service is visible globally
... bridge between Alexa and WoT devices
uday: allocate devices dynamically?
mccool: want to talk to whatever Things
dynamically
... and generate voice interface for them
... turn on/off
... would see semantic tagging
... the idea is more generic one
... likewise OCF Thing
uday: Alexa already knows about the devices?
mccool: no, dynamically asks about that
kaz: it seems there is a list of issues on p3
mccool: yeah
... would like to demonstrate semantic interoperability
... proxy things could be useful but not unique
... there could be more dynamic mechanism
... also think we need some directory service somewhere
matsu: tx for your comments
... would be useful to have those points on the wiki
... and discuss it in detail later
mccool: ok
(Michal_Koster joins)
matsu: Koster, do you have any update
on your side?
... device servient, etc.
kaz: expectation for your devices and servients?
koster: Smart Thing devices
... exposed as a "device"
mccool: as an OCF device?
koster: yeah
... light and motion sensor
... will show the information on the f2f wiki
matsu: ok
... maybe Matthias could provide a remote proxy as well
... Daniel and Sebastian, do you know if Siemens can provide app
servient and proxy servient?
dape: finish by beginning of Nov but not completed
sebastian: working on that
... some slide maybe in 2 weeks
... about how it works
... btw, "TD repository" is missing here
... to find all the accessible Things
mccool: yeah, how to discover
Things/services
... web services are visible and accessible, though
matsu: TD repository is one of the
important issues
... would like to talk about that in detail later
dape: not only who but one in the local side and another in the Internet side
kaz: why don't you explain the 2nd slide, Matsukura-san?
matsu: (go ahead to the 2nd
slide)
... devices on some locations
... applications can be located in the Internet side
mccool: one assumption here is all the
applications work on the Internet side
... on the other hand there can be apps on the local side like fog
apps
... also NATs accept all the global addresses?
koster: accepts all the incoming addresses. right?
mccool: we can reach between different
networks
... there are 3 different networks here
koster: 2 different networks via a remote proxy
mccool: right
matsu: this slide shows the
combination of possible servients
... we want to get information for the PlugFest
... e.g., what kind of devices will be used
... and application scenario
kaz: and the interface between servients
matsu: yes
... (p3: Issues for TPAC plugfest)
... issues
... 1. interface between servients
... need to think authentication, discovery/TD exchange,
firewall/NAT, Event operation
... 2. TD management
... need to think about how to create the URI
mccool: we should try discovery API
... e.g., the one of node-wot
... should be set up to look up local TD directory
... and need to set up TD directory
... other people use something other than node-wot
... in that case, how to handle discovery?
... where is "it"?
koster: one common directory to discover TD?
mccool: Fujitsu may have their own
implementation for discovery
... local proxy could delegate discovery capability to remote
proxy
koster: we've not clarify how to
handle that yet
... the basic case is having everything within home
mccool: the basic case could be having
one global cashing directory
... would be happy to have one single point for now
kaz: confirm everybody happy and
provide servients
... and file issues
mccool: wot repo?
kaz: that's fine
mccool: we have 2 local proxies for the local network in SF
matsu: and each of the two remote
servients correspond to one of them
... we should clarify the way how to register Things
mccool: idea here to create a generic proxy service?
matsu: right
mccool: we need to document the interface
for that purpose
... discover and identify the devices
koster: proxies have both the capabilities of expose/consume
mccool: need to define TD for the local
proxy servient
... how to search devices within the local network from the
outside?
... discovery the Things dynamically or any provisioning?
koster: we have multiple
problems
... we have local proxy and remote proxy
... what is exposed for the north-bound?
mccool: OCF device talks with CoAP
koster: the assumption here is
... possibly have multiple protocols, CoAP, MQTT, etc.
... or simply HTTP
mccool: I'm creating a bridge
... could create a proxy as well
... this diagram is misleading
... OCF device doesn't know the local proxy servient
... on the other hand, the local proxy servient need to talk with
the device servient
kaz: we should clarify that the green box "device servient" is just a device which handles the specific devices
mccool: yes, for my side, the blue box itself is a servient
kaz: I guess the point here with the blue box is describe the pattern of Panasonic's system
mccool: yeah
... both patterns make sense
... device servient+device vs servient device(which includes both
device servient and device at once)
koster: in that case, some of the blue boxes can be directory connected to the yellow box (=local proxy servient)
kaz: so we should rather start with green boxes which expose device capability
mccool: right
matsu: ok
... would suggest you also generate diagrams of your systems and
descriptions :)
mccool: where to store the resources?
kaz: how about wot repo
... under plugfest sub directory?
<McCool> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_4-10_November_2017,_Burlingame,_CA,_USA
mccool: visit the above f2f wiki
... point the wot repo
... and diagrams, etc.
<McCool> issue prefix "PlugFest4Q17"
mccool: and issues should have prefix like "PlugFest4Q17"
kaz: and we can create a label "PlugFest4Q17" as well
mccool: right
<McCool> and please document that in a section of the wiki page above...
kaz: at some point we could think
about MD and HTML on the wot/plugfest repo as well
... btw, the minutes to be published publicly?
all: fine
[adjourned]