See also: IRC log
<inserted> scribenick: ted
Wonsuk: we have two task forces,
one on media tuning and other on location based services
... we are working on a draft for LBS and should hear more from
Qing An
... for media tuning we are comparing use cases with tv
controller api wg
... Ryan regularly joins their wg calls
... unfortunately he is not here to provide more details on
their findings and any gaps
... perhaps Kaz as team contact there can provide some more
information
Kaz: the expectation is the tv
control specification will take into account Ryan's
proposals
... it would also be nice if they changed their spec and
variable names from tv to media
Wonsuk: Ryan already made a proposal including our use cases. have those been incorporated yet or still under discussion?
Kaz: still under discussion
... i wonder however if there should be some service level spec
like we are doing for vehicle signals in addition to client
side api
Wonsuk: we need to also line with Genivi
Kevin: there are others more involved in media in JLR than Adam or I
Adam: we have a[n internal] standard attribute naming convention
Kevin: drm is an issue in this area. there are often proprietary SDK necessary and not just opening a URI
<inserted> scribenick: kaz
(some more discussion on DRM and EME)
<hira> irc is still alive?
<hira> Could you open the files of powepoint and excel I sent by e-mail 7 hours before?
(disconnected from the Internet :( )
hira: question on the interface
... between what and what?
qa: trying to define some API which could be used commonly
kaz: this API is not WebSocket I/F layer but the Web App API I/F layer
hira: ok
wonsuk: what is your intention of
this spec?
... Google has all the APIs to handle maps
qa: interact with the Map
object
... different from the mobile map system
... for mobile apps, the user him/her-self handles the map
apps
... however, in the driving case, most of the time the driver
him/her-self doesn't want to handle the map apps
... so we need some more additional APIs to improve the user
experience for driving use cases, e.g., controring the speed of map
scroll
... many of the APIs could be similar to the Google Map API but we
need to have some more universal API definition which could be
applied to IVI use cases
kl: is it necessary to provide
concrete Web APIs for that purpose?
... this API could be used within the car
... detailed Map API really needs to be (re)defined for IVI
purposes?
... also maybe we should check the exisiting map-related APIs
qa: the reason why we need a Web API
is the same as why we need vehicle information access API
... we need some method to access the information
... the second point is comparison with the exisiting map
APIs
... not yet done the survey
... but we need a lot of addtional features than the existing
Geolocation API
wonsuk: if Qing An is OK, we'd like to change the topic and continue this discussion in the afternoon, because we have Hira-san's comments on VSS and the joint session with the WoT IG
[ AM break for 15 mins ]
(network connection recovered)
hira: yellow lines highlighted
show missing features
... also location information is incompatible the existing
Geolocation API
... some data is missing in both VSS and Vehicle data, e.g.,
fuel tank capacity, number of tires
kevin: good input
hira: comments appreciated
wonsuk: your proposal is very clear
ted: comments
... agree there are signals missing and they will extend over
time
... they welcome contributions and would suggest doing so in
logical modest sized pull requests in case any warrant further
discussion before accepting
hira: user ID is important
... we've not defined user ID yet
<ted> some are controversial or open to debate such as vin (privacy but that can be addressed by access control) and number of doors is something that can be deduced with simple count of body.door.*
wonsuk: we need to keep
discussing this topic
... and will discuss this during the upcoming Genivi meeting in
October
... tx for your great contribution
<ted> [hira, looking at your spreadsheet more i wonder if you should use meters instead of centimeters for various things like acceleration]
<ted> [if your spreadhsheet of existing signals is correct it seems vss is inconsistent in units of measurement. grams in some places, kilos other, mm and inches. that might be because of what is commonly used terminology for a given part but in my opinion would be best to have in common]
<ted> [i'll take another look at vss and contact magnus about that]
WoT guys have joined
introduction from the WoT side
Kajimoto: panasonic
Joerg: Siemens
Kangchan: ETRI
Matthias: Siemens
Wonsuk: ETRI
Sebasitian: Siemens
Ted: W3C
Kevin: JLR
Adam: JLR
Victor: Siemens
Natasha: GSMA
Matsumura: NHK
Daniel: Siemens
Takuki: Fujitsu
Bernard: W3C
Jonathan: ETRI
Michael: Intel
Kaz: W3C
Qing_An: Alibaba
Yingying: W3C
Junichi: KDDI
Hamid Panasonic
Ohsumi: Panasoinc
Nunokawa: Keio
Andrei: @@1
Mohammed: Orange
Matsuo: Softbank
Yongjue: Softbank
wonsuk: shows the agenda on the
screen
... current status
... host name of "wwwivi" and sub-protocol name
... description method
... HTTP error code
... security and privacy
... any comments?
mm: relationship with device and sensors?
ted: we had discussion with them
wonsuk: will explain the work of the Automotive WG
<urata_access> HI, It looks WebEx has disconnected..
<hira> WebEX has been disconnected!
<hira> TKS
kevin: we've changed our approach
from JS API to WebSocket-based interface
... (shows Vechicle Signal Server spec)
<ted> [web socket service available in-vehicle network only]
@@@v
kevin: (shows slides)
@@@s
kevin: Proposed Vehicle Data Infrastructure
<ted> [800+ signals in Vehicle Signal Specification (VSS) at present and growing]
kevin: Data Structure (VSS) by
GENIVI (Author: Magnus Feuer)
... Server Spec by W3C (Author: Kevin Gavigan, Adam
Crofts)
... Client Spec by W3C (Author: Powell Kinney)
... (goes back to the spec draft)
<JonathanJ> tentative agenda - https://lists.w3.org/Archives/Public/public-wot-ig/2016Sep/0025.html
-> http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html spec draft
kevin: security and privacy considerations
mm: one on one security?
ted: token is used
seba: why do you define WebSocket connection?
kevin: initiated by Tobie from
the Device API group
... as more generic interface
mm: can you bootstrap REST interface based on this?
kevin: JS library depends on the
client spec
... (shows the architecture diagram)
... "System" at the bottom
... we need a secure gateway
... the "System" covers almost all the car environment
... (shows the VSS tree diagram)
... tree-based structure
... logical structure of vehicle-related signals
mm: popular design?
kevin: have been discussed within GENIVI
<ted> VSS
<scribe> ... (continues the explanation on the architecture diagram)
<ted> VSS presentation
UNKNOWN_SPEAKER: WebSocket
Vehicle Signal Server (WVSS)
... each node of the VSS tree is a class
... (goes back to the architecture diagram)
... JavaScript Library exposes high-level APIs for the Web
clients
ted: provides some more background information
mm: sounds like synchronized documents on two sides
kevin: the Vehicle Signal Client API is easier to handle for Web developers
matthias: why do you use
websockets?
... sounds like reinventing protocols
... on the top of socket connection
kevin: good question
... WebSocket Vehicle Signal Server (WVSS) exposes Vehicle
Signal Server API
... possibly with runtimes which don't have UI
... and possibly connected with devices without fixed IP
address
daniel: data format?
kevin: first version considers
JSON
... could add other formats later
ted: there are a number of
different approaches
... subscription of data would make sense because data on
vehicles is huge
mm: how to handle "sleep"?
... WebSocket connection always open?
kevin: examples of WebSocket
APIs
... create WebSocket connection
... sending "ACTION: authorize"
... and the token
... and send "ACTION: get" with "path:
signal.public.global.speed"
... another good example on "subscription"
... and message structure (http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html#message-structure)
mm: overlaps with CSS filtering and so on
Kevin: data tree search is
similar to CSS filtering
... (explains the ladder diagram on the interface between the
client and the server)
... this is the last slide
... client asks the server about "vehicle.speed" and the server
responds to the client with the vehicle.speed
seba: access protection?
... only one way to handle the security token?
kevin: at the moment our spirit
is to be open
... the client goes to some authority to get the token
mm: you have defined the
mechanism inside
... don't care of the mechanism to get token from outside
seba: WoT's Thing Description also needs to handle security
kevin: the client should handle
at least the error code of expired or invalid
... we can have a private tree
mm: one more thing to ask is use
cases
... what kind use cases are in your scope?
kevin: getting/setting signal
within the vehicle
... used on vehicle to talk with outside for convoy
driving
... manufacturers need to see what to be exposed by the Vehicle
Signal Specification
... VSS returns metadata
wonsuk: we're getting out of time
kaz: maybe would make sense to have joint calls on the regular basis?
matthias: should identify specific topics beforehand
@@@slidesM
matthias: What is the Web of
Things?
... Web of Things: applications
... W3C WoT Mission
... fill the gaps to interconnect different approaches by
different consortia
... Status
... WoT IG for 1.5 years
... 4 IG Notes to be published
... several implementations based on the PlugFest
experience
... AC review for WoT WG ongoing
... WoT demo on Wednesday at Auditorium III
wonsuk: when do you expect for the WG to get launched
matthias: in October?
... W3C WoT Building Blocks
... Protocol Bindings
<ying_ying> https://www.w3.org/WoT/IG/wiki/Roadmap
matthias: Thing Description
... Scripting API
... Cross-cutting Security & Privacy
-> http://w3c.github.io/wot/current-practices/wot-practices.html current practice doc
matthias: see the building blocks
quickly
... Protocol binding
... Web API for Things
... various protocols
... multiple bindings per Thing possible
... Common Interaction Model
... Resource Model
... two loads: consuming Things is client role
... exposing Things is server role
... usually both roles at the same time
... so use "Servient" which has both the capabilities of server
and client
... move on to Thing Description
... How to interact with Things?
... Thing Description (TD)
... linked data vocabularies
... no fixed classes or types but re-usable vocab
... machine-understandable semantics
... W3C Thing Description
... for now serialied as JSON-LD
... could be compressed using EXI, etc.
... extensible with domain-specific vocab
... maybe automotive or other consortia
... could be plugged in the Thing Description
... TD example (JSON-LD)
... @context, @type, name, uris, encodings, security, ...
... 3 interaction patterns: property, action and event
... next
... Scripting API
... common runtime enables portable apps
... from servient by vendor A to another servient by vendor
B
... Discovery API, Server API and Client API
... Script example (Expose Thing)
mm: could be applied to virtual things
matthias: Script Example (Consume
Thing) - client side
... summarization:
... Thing Implementation: WoT Servient
... application logic
... resource model
... Thing Description
... Thing Description includes all the metadata
... WoT Servient on Thing itself
... WoT Servient on Integration Hub
... WoT Servient in the Cloud
... Connected Car Scenario
kaji: the CAN layer is a
proprietary layer
... on be half of the ECUs on CAN, the Gateway (as a WoT
Servient) exposes data to the cloud side (as a WoT Client)
matthias: Online Resources
... we can continue discussions during break, etc.
wonsuk: questions?
kevin: how to manage trust?
... how to recognize if I can get connected
matthias: depending on the Web
architecture
... we could use additional plugin to handle security to Thing
Description
... we're not inventing new mechanism for security
... but working with IETF about authentication
mm: do we need some special mechanism for metadata?
kevin: we're working on the
architecture document as well
... we can reuse the existing mechanism, e.g., OCF
(some more discussion about cooperation with other consortia)
matthias: shows the slide of "W3C WoT Mission"
kaz: @@k
... also maybe automotive group might want the TD to have a
capability to refer to external data definition, e.g., VSS
matthias: interesting point
seba: guess each manufacture has
their own VSS tree?
... Thing Description is more abstract
kevin: powerful to have
generalized level of data
... interested in how to bridge
mm: interested in finding use cases
kaji: shows a use case: Comfortable Welcome Home
mm: home and car, industry and car, car and car, etc.
kaji: IVI recognizes the distance
between the current geometry positiom and my home
... if the distance becomes less than threshold such as 3km,
then the air conditioner turns on
... the WoT Servient for IVI identifies who I am
... IVI gets home geometry, current geometry position of the
car, and get current speed, etc.
wonsuk: tx
kevin: can quickly show another
use case
... Potential Attackers
... external attackers and internal attackers
... lots of potential attackers
... Example Use Case
... ADAS - controller sets safety critical controls
mm: hand-over issue
... also how to do mash-up
jh: lots to think especially for car use cases
kevin: inputs into the ADAS
control modlue, e.g., camera
... another example on convoy driving
jh: you're focused on the
vehicle-internal communication
... but would be interesting to think of joint work with
others
kevin: so far Automotive participants, e.g., JLR are interested in car use cases
matthias: could be involved in the demo even with some simple functionalities
kevin: like speed meter, steering wheel angle
mm: maybe we should start with sensing part of sensing and actuation
wonsuk: shows the agenda
... we're out of time with the first item (current status of
each group activity)
... if you agree, we might want to have joint calls
... we need some more internal discussion too
... after we can set up a joint call
matthias: would suggest we have
proposals on some specific topics
... maybe we could find some paring between your group and our
group
wonsuk: sounds good
... any other opinions?
(none)
wonsuk: tx!
[ lunch till 2pm ]
[ after lunch ]
da: from TAG
... you can issue an issue on TAG's Github if needed
hamid: what are the features in
the navigation systems are already available
... are you recreating that mechanism?
... I use navigation with my car
... e.g., getting into some specific area and detect that is
missing
... what is the real use case for this Map API work?
wonsuk: that (=use case discussion) was done before
qa: last year?
... there are many kinds of navigation system available
... compatibility with Web technology based on
abstraction
... GENIVI also joins this work
... and discuss what the expected Web API should be
... this is the same to the other navigation service providers
too
hamid: you'll provide the same service as the one we have today?
adam: we'll be able to integrate various IVI services with navigation service
kevin: we should be careful not to reinvent wheels
qa: goes ahead
... Interface 'Map'
... POI Use Cases
... point of interest
... keyword searching by default
... keyword searching nearby (geometrics)
... keyword searching within bound
... get detailed POI info
... (goes through the API description)
... basic POI object
... Driving API
... Inteface 'Driving'
<urata_access> Hi, could you reconnect WebEx?
qa: Interface 'DriveRoute'
-> https://lists.w3.org/Archives/Public/public-automotive/2016Sep/att-0027/LBS-api-webidl-draft.docx Qing An's writeup
<urata_access> WebEx is OK!
<ted> scribenick: ted
<urata_access> Thanks ted, ashimura-san
QingAn: API design is very
detailed getting into eg roadID
... geocoder use cases are for forwarding or reverse
geocoding
[geocoder interface definition]
QingAn: result of getLocation
returns geographic coordinates and getAddress gets the address
description
... objectives include api best practice and furthering use
cases
Kevin: is there a spatial data
group in w3c that may already be trying to come up with
similar?
... there may be a number of ways to define the same thing for
eg POI
<AdamC> https://www.w3.org/2015/spatial/wiki/Main_Page
QingAn: which groups?
<AdamC> Spatial Data on the Web WG^
Adam: spatial data
Kevin: they're involved with the open geospatial consortium
QingAn: Philippe Colliet has been intending to provide the Genivi API side for geo but understand only part of it would be ready for the AMM in October
Wonsuk: for vehicle signals we
have client side and server side specs
... this is purely client side
QingAn: we have not found a very
good solution based on web sockets
... we may need to get some outside assistance for such an
approach
Wonsuk: we should make a clearer architectural picture for LBS
QingAn: for VSS/signal web socket
we assume the server is located in the vehicle itself
... LBS service could be either on or off vehicle
Ted: or a mix with cache and remote eg traffic data
Dan_Kaminsky: what would you see cached and in what format?
QingAn: format will vary based on the customer
Kevin: one of the challenges for SOTA is updating large maps data over cell network
Dan: you might want to check instant.io and how they are handling sporadic connectivity issues
<wonsuk> https://instant.io/
Dan: it allows loss tolerate and latency aware communication
QingAn: we need to first define what data should be cached vehicle side and what needs to be updated in real time
Dan: it looks like you were integrating directly into the DOM. how do you see the integration?
QingAn: we initially took a webidl approach and you could have it available to the DOM
Dan: you could expose this as a
REST endpoint and have a thin wrapper to get similar
functionality
... we keep seeing people try to add things to the
browser
... which provides a means for external sites (and advertisers)
to potentially manipulate
... to the degree you can compartmentalize nicely it is really
worthwhile
[high level vehicle architecture and security discussion - can't scribe and talk at the same time]
@@links to gunnar's diagram and previous meeting minutes
Kevin: we have other diagrams
showing the various other levels touched up in brief here
... VSS provides tree like structure of signals information
available
Dan: CAN to JSON essentially
Kevin: yes
Dan: and you are trying to control which clients can access which
Kevin: correct using a token structure that an app can provide to underlying socket service that can authenticate it and restrict
Dan: what else are you using to protect?
Kevin: wss - web socket over ssl
Dan: what about outside connectivity interactions?
Kevin: we are not focusing on that at present
Ted: i've had some on thoughts for third party developer guidelines if we later see level of cooperation necessary among OEM to impose them https://www.w3.org/2016/04/guidelines-article.html
Dan: the big question is what the
bad guy might do in a situation like this?
... the secure gateway that wasn't part of the diagram was the
first thing i was looking for
... critical systems should be completely separated
... an SELinux type approach is fine grained but a grain might
be missed
... it is ok for a gas pedal to make the car accelerate not the
radio
... scope the stuff that could kill someone out
Kevin: there are people who want to be able to have deliberate limited remote access
Dan: fine but it should be a
separate and distinct system, unrelated to this
... you will be compromised components
... an ad can be downloaded and contain script that runs in
your web runtime
... isolation is the name of the game
... forget fine grained
... there will be a bug discovered
... as simple as you can make the constraint between CAN bus
and your web socket the better
... the crypto you should focus most on keys for protecting
software updates
... I would probably define a chain model. define a finite
number of chains of what you want to expose
... the components that are permitted to the web should be
separate from ones that can talk to the can bus
Hamid: suppose someone lost a key
to unlock and start their car. what kind of ability do you need
to provide them?
... that is a threat analysis and defining the core
problem
... OEM do not buy more computers readily
Dan: when you have to do
something inconvenient you need to think of the worst thing
someone can misuse that
... are you doing that sort of analysis in your spec?
Ted: we are doing threat tree analysis within Genivi security group
Dan: you need to think of the
risks that exist already and you are adding
... you should define where to air gap
[discussion of ecosystem]
Dan: check out https://autoclave.run/ sometime :)
(re sandboxing)
Dan: how much is this similar to
OBD2?
... in terms of data being exposed
Kevin: similar
Dan: maybe you work work on secure OBD2-like interface and go from there
Ted: some and hopefully in time all OEM will be creating those as secure gateways to CAN. essentially breaking pins to prevent writes in your RS232 model
Dan: check out what George Hotz did with his car and playstation
<drkevg> George Hotz: https://www.yahoo.com/news/george-hotzs-999-autonomous-driving-214211225.html
Dan: what about bluetooth?
Ted: not our part of the stack but the models we've been seeing definitely do not trust them
<urata_access> Hi, WebEx is disconnected again. Could you reconnect?
<hira> WebEX has been disconnected again!
<hira> Recovered, TKS
Wonsuk summarizes methods Powell outlined in wiki
[group provides highlights of F2F to Rudi]
Wonsuk: we need to resync the
client API with the socket one as there are some differences
such as authenticate in client API only having concept of a
single token
... also filters
Ted: yes re filters or the JS library implementation could potentially keep that simple and impose filters itself and not give the client the option
[group agrees we should sync with Powell]
Junichi: it is possible to do similar with authenticate
Ted: true, the client library could have token[s] and provide those to web socket in establishing connection
Kevin: there is no method for removing tokens
Ted: that could be done by passing no parameter to authenticate
Adam: callback method to subscribe
Wonsuk: what is the use case for
raw?
... I guess we need to check with Powell
Junichi: This is for a session tomorrow at TPAC
<urata_access> It looks WebEx audio is lost..
<hira> RCVD
<urata_access> Thanks!
-> https://lists.w3.org/Archives/Member/member-automotive/2016Sep/att-0031/http-migration-in-local-network-r2.pptx Junichi's slides
<urata_access> thanks again!
Junichi: in this use case people
want to store local video
... PLEX solution. provide uri and username
... browser will log into application server
... browser knows relationship. in example hostname is based on
local IP address
... and domain name from external service
... certificate is a wildcard certificate for service domain
name
... reason for this is CA generally consider .local hostnames
and IP addresses as bad practice
... our wwwivi hostname in spec is a similar problem since we
want to use wss
... this PLEX solution might provide some ideas for us
... we should have a plan for handling certificate
[slide of local device network]
Junichi: there are many stakeholders in our case with different spheres of influence (demonstrated by circles on diagram)
Ted: previously we discussed self
signed under /etc/ssl/ but you very clearly demonstrate the
bigger problem
... it is useful to be able to revoke certificates since a mitm
attack with stolen private key could then in turn harvest
tokens and data
Kevin: we need to be able to work
when there is no connectivity (ability to verify certs with an
external CA)
... there are devices (HSM) that can sign items passed to it
with a private key
<inserted> scribenick: kaz
Kevin: QNX also has some mechanism
<ted> scribenick: ted
Kevin: wondering about MS' secure boot model
Kaz: I attended joint meeting
between WoT & TV IG
... they are interested in a cloud browser with tv being
client
... they are discussing concrete use cases
... the model they are considering between cloud browser and tv
is similar to ours
... we will talk with them more at a future point
Wonsuk: what would be the data
format from cloud browser service
... this is useful for delivering features to a thinner client
and offloading computation
... there are limitations with this model
... such as handling user interactions
... do they have ideas for formats after rendering in cloud
browser?
Kaz: yeah, here is a more detailed diagram
@@uri
Kaz: there are several data formats and procedures for handling this
<yingying_> https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Architecture
Ted: as Kevin just mentioned
during Junichi's CA topic there are plenty of times where a
vehicle looses its internet connection
... cloud browser would need to be on the vehicle and not sure
how it would be useful for signals information, maybe for media
tuning
Wonsuk: WoT&TV TF is looking at this for media stream and could make sense for us
<urata_access> Thanks everyone. Good bye!
<kaz> [ adjourned ]
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ryan/Ryan/ Succeeded: s/and not just opening/and not just opening a URI/ Succeeded: s/agree there are signals missing/agree there are signals missing and they will extend over time/ Succeeded: s/contribution to be included using pull request/they welcome contributions and would suggest doing so in logical modest sized pull requests in case any warrant further discussion before accepting/ Succeeded: s/@@@:/Hamid/ Succeeded: s/Jonathan:/Jonathan: ETRI/ Succeeded: s/server0/server)/ Succeeded: s/mahcne/machine/ Succeeded: s/THing/Thing/ Succeeded: s/Disc./Discovery/ Succeeded: s/other/others/ Succeeded: s/WG/group/ Succeeded: s/2pm/2pm ]/ Succeeded: i/from TAG/topic: Comment from TAG Succeeded: s/@@1/Dan/ Succeeded: s/Dan:/Dan_Kaminsky:/ Succeeded: s/Hirabayashi (KDDI)/Hirabayashi(KDDI;remote)/ Succeeded: i/DRM and EME/scribenick: kaz Succeeded: i/we have two task forces/scribenick: ted Succeeded: s|Ted @@ on thoughts for third party developer guidelines if we later see level of cooperation|Ted: i've had some on thoughts for third party developer guidelines if we later see level of cooperation necessary among OEM to impose them https://www.w3.org/2016/04/guidelines-article.html| Succeeded: s/ODB2/OBD2/g Succeeded: s/そちら、様子はどうですか?// Succeeded: i/QNX/scribenick: kaz Found ScribeNick: ted Found ScribeNick: kaz Found ScribeNick: ted Found ScribeNick: kaz Found ScribeNick: ted Inferring Scribes: ted, kaz Scribes: ted, kaz ScribeNicks: ted, kaz Present: Kangchan_Lee(ETRI) Wonsuk_Lee(ETRI) Ted_Guild(W3C) Kevin_Gavigan(JLR) Adam_Crofts(JLR) YoungJae_Shin(Softbank) Matsuo_Suzuki(Softbank) Hamid_Amir_Alikhani(Panasonic) Qing_An(Alibaba) Yingying_Chen(W3C) Junichi_Hashimoto(KDDI) Kaz_Ashimura(W3C) Michael_McCool(Intel) Mohammed_Dadas(Orange) Uday_Davuluru(RWE) Kazuo_Kajimoto(Panasonic) Joerg_Heuer(Siemens) Sebastian_Kaebisch(Siemens) Victor_Charpenay(Siemens) Daniel_Peintner(Siemens) Philipp_Hoschka(W3C) Bernard_Gidon(W3C) Jonathan_Jeon(ETRI) Yoshiaki_Ohsumi(Panasonic) Kenichi_Nunokawa(Keio) Taizo_Kinoshita(Hitachi) Daniel_Appelquist(TAG/Samsung) Bill_Scannell(White_Ops) Dan_Kaminsky(White_Ops) Dong_Wenyu(China_Mobile) Hirabayashi(KDDI;remote) Urata(ACCESS;remote) Rudolf_Streif(JLR;remote) Found Date: 20 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/20-auto-minutes.html People with action items:[End of scribe.perl diagnostic output]