W3C

- DRAFT -

Automotive Working Group Teleconference

20 Sep 2016

See also: IRC log

Attendees

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)
Regrets
Chair
Wonsuk
Scribe
ted, kaz

Contents


Auto BG update

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

VSS review - Hira

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]

Joint discussion with WoT

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

WoT update

@@@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 ]

Comment from TAG

da: from TAG
... you can issue an issue on TAG's Github if needed

Map API (revisited)

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

<AdamC> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#JavaScript_Library_Interface_Guidelines

JS client API

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

<wonsuk> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#JavaScript_Library_Interface_Guidelines

HTTPS migration in local network

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

Web & TV IG's Cloud Browser TF report

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 ]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/09/21 06:26:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]