00:00:15 [EXI vs gzipped BSON, CBOR] 00:01:11 ... still smaller across the board 00:01:32 ... EXI is not compression 00:02:06 ... when people share data they use a standard api to produce xml or json and might compress before sending to other system 00:02:31 ... EXI writes an EXI binary stream instead of XML 00:02:45 ... it does not require XML 00:03:29 ... but it can fit underneath an xml library 00:04:09 [slide listing the multitude of XML definitions - eg RDF, SVG...] 00:04:21 [all the XML based implementations] 00:05:20 ... XML aware applications tend to produce a representation of the XML (SAX or DOM) and not the XML itself 00:05:51 ... you can develop and test in pure XML and then switch to EXI after 00:06:16 ... adoption wise: we are in 400k automobiles in the U.S. and expanding 00:06:31 ... it is being used for smart energy (appliances and power meters) 00:06:58 ... it is being used for digital radios used by emergency responders 00:07:03 ... gaming industry 00:07:43 ... IoT, W3C, V2G (vehicle to grid for electric vehicles), US DOD and intelligence communities have adopted it 00:07:57 [list of better known customers] 00:08:06 ... banking and finance 00:08:28 ... VW Car-Net uses it 00:09:09 ... this is used in fighter aircraft for both internal communication on the bus and external 00:09:28 ... it is being flight tested in F22 and F35 00:09:48 dave: how long has the spec been around? 00:10:09 john: 2011 for the latest spec. it started back in 2004 00:10:34 -> http://www.w3.org/TR/2011/REC-exi-20110310/ EXI first edition 00:10:37 junichi: how about error detection? 00:10:39 -> http://www.w3.org/TR/exi/ EXI second edition 00:10:55 john: that is in a different layer of the stack as is encryption and security 00:11:24 dan: you mentioned how much more efficient Agile Delta's system is, how does that compare to others? 00:11:38 john: ours was the reference implementation 00:11:45 s/2011 for the latest spec/2011 for the first edition recommendation/ 00:12:01 ... not a fair comparison since we had several years head start 00:12:05 s/started back in 2004/second edition Rec in 2014/ 00:12:20 ... i would say 16-30x faster and maybe 2-6x smaller 00:12:50 dave: are there many implementations? 00:13:01 paul lists 4 from w3c site 00:13:23 john: cisco, arch, seimens. some private implementations 00:13:53 dave: i'm not seeing python libraries for example 00:14:17 john: it is not widely known. we have a high ratio of engineers to marketers 00:14:42 -> http://www.w3.org/XML/EXI/#implementations publicly available EXI implementations 00:15:03 ivan: people are also becoming lazier with efficiency and throw more hardware at solutions 00:15:30 ... that is going to be needed in IoT 00:15:39 john: those who know about it generally adopt it 00:19:51 ted: so as it applies to our json based spec... when there is need to not interact with the user but send large volumes of data an app using the json api can collect and package up in exi before streaming out 00:20:21 dave: it makes more sense to use json for browser interfaces 00:20:45 john: very true but when you are paying for bandwidth you need to be as compact as possible 00:22:26 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html ted 00:22:58 shinjiro: can you convery back to xml? 00:23:09 john: yes, it is called transcoding 00:23:41 ivan: what about open source data stream sniffers? 00:23:41 i/shinjiro:/kaz: there is discussion on EXI within the WoT IG as well, so maybe it would make sense to have joint discussion with them, e.g., during TPAC 2015 in Sapporo 00:24:03 john: yes you can put a plugin into wireshark for example to see xml extraction 00:24:59 [ think EXI Primer http://www.w3.org/TR/exi-primer/ is a good starting point to know EXI ] 00:25:14 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html ted 00:25:56 Meeting: Automotive WG f2f meeting in Seattle 00:26:14 rrsagent, draft minutes 00:26:14 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_ 16:13:46 RRSAgent has joined #auto 16:13:46 logging to http://www.w3.org/2015/07/29-auto-irc 16:16:26 kaz_ has joined #auto 16:16:43 rrsagent, make log public 16:16:47 rrsagent, draft minutes 16:16:47 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_ 16:18:14 scribenick: kaz_ 16:18:25 topic: Agenda 16:18:40 Use Case Mechanism/Infrastructure 16:18:45 Breakouts 16:18:53 - Use Case 16:19:29 -- Categorization 16:19:33 --- Security 16:19:36 --- Privacy 16:19:44 --- Remote Access 16:19:56 --- Higher Level Functionality 16:20:02 --- Identification 16:20:07 -- Testing 16:20:11 2pm 16:20:20 urata_access has joined #auto 16:20:23 - Presentations 16:20:34 --- @@@1 16:20:37 --- @@@2 16:20:43 Present+ Wonsuk_Lee 16:20:43 topic: Introduction 16:20:51 wonsuk: from ETRI 16:21:00 rrsagent, draft minutes 16:21:00 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_ 16:21:38 i/topic: Agenda/[ Day2 ]/ 16:21:46 use case spreadsheet: https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=867261678 16:22:40 paul has joined #auto 16:23:03 Greg has joined #auto 16:24:13 day2_attendees: Dan, Paul, Greg, Ted, Wonsuk, Sakamoto, Ivan, Urata, Kaz, Hashimoto, Hirabayashi 16:24:24 i/[EXI vs gzipped BSON, CBOR]/scribenick: ted/ 16:24:28 rrsagent, draft minutes 16:24:28 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_ 16:26:32 Dan has joined #auto 16:26:53 Ivan has joined #auto 16:27:07 I have arrived 16:27:43 https://klg.webex.com/klg/j.php?MTID=m3533658821a3b35ae42e5e77fcf43553 16:28:05 Meeting number: 731 650 244 Meeting password: Web729 16:30:06 topic: Use Cases 16:30:22 scribenick: kaz 16:30:29 http://www.w3.org/auto/wg/wiki/Use_Cases 16:30:38 -> https://www.w3.org/auto/security/wiki/Use_Cases 16:30:38 https://www.w3.org/auto/security/wiki/Use_Cases 16:30:47 paul: spreadsheet put together by Hashimoto-san 16:30:53 ... and wiki by Kevin 16:32:09 s/wiki by Kevin/Use Case Wiki by Qing An/ 16:32:20 ... Security Use Case Wiki by Kevin 16:34:45 (quick review by each) 16:35:56 -> https://www.w3.org/auto/security/wiki/Use_Cases Kevin's Security Use Cases 16:36:06 paul: what do we do on ADAS? 16:37:36 ... security issue is authentication 16:40:42 -> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=867261678 spreadsheet on "Use Cases and Concerns" 16:42:09 paul: the spec doesn't cover logging 16:43:58 ... another point is performance 16:44:38 ... what do you do for frequent fresh rate? 16:44:59 ... also register items for logging? 16:46:02 greg: frequency of ADAS information activation? 16:46:54 dan: would be helpful to capture some high level use cases 16:48:03 paul: would be great to capture high level use cases like logging ADAS information 16:48:29 ... this looks like V2X thing 16:49:28 ivan: does the spec have a space for future systems? 16:49:39 ... robust to system-wide 16:50:09 paul: can you generalize operations? 16:50:18 ... identifying data 16:51:05 paul: could be a separate interface 16:53:23 ted: no. 6 from the spreadsheet vs. use case 4 from Kevin's wiki 16:54:13 junichi: we don't have to merge all the use cases during the meeting today 16:58:24 ted: require data sharing stated by governmental/federal instructions 16:58:50 ... vs. sharing data with friends 16:59:16 hira: the point I think is granularity of the data 17:00:06 ted: people might be interested in average speed 17:00:15 ... more efficient driving 17:01:16 paul: we should capture high level use cases first 17:01:35 hira: after that we should prioritize the use cases, etc. 17:03:05 paul: the goal is identifying use cases which are influential to our specs 17:03:16 ... from the viewpoint of security and privacy 17:03:31 ... our focus is the specs 17:12:04 kaz: btw, it would be better to have an ID (or URL link to the original wiki-based use case description) within the spreadsheet to identify each use case described on the wiki pages 17:16:38 paul: No. 25: driver would like to remotely start vehicle... 17:18:57 (Adam joins) 17:19:10 paul: discussing high level use cases 17:19:32 ... to identify the priority 17:20:30 ... auto maker's applications have complete access to all the data 17:20:47 ... 3rd party applications just have access to part of the data 17:23:58 greg: automaker has concerns around impact compliance with emissions regulations due to 3rd party access 17:24:46 ... security concern is giving access to vehicle control 17:24:53 s/access/direct access/ 17:25:34 AdamC has joined #auto 17:25:53 paul: meaning accessing a server rather than directly accessing the vehicle? 17:26:44 Ivan has joined #auto 17:27:17 ... (updated the spreadsheet based on the discussion) 17:28:51 wonsuk: smart things, a venture company, provides a cloud-based mechanism to control smart home devices 17:29:26 ... the cloud service can make decision on who can access what 17:32:36 kaz: in that case, the cloud service has authentication capability like fingerprinting? 17:32:44 wonsuk: not 100% sure 17:32:56 ... but should have some mechanism for security 17:33:32 ... could be fingerprinting plus passwords for payment service 17:37:03 paul: if HTML5-based headunit use JavaScript to send the data to the cloud server, the speed might be problematic 17:39:08 kaz: Sakamoto-san's demonstration in the afternoon is related to this problem 17:39:14 JonathanJ2 has joined #auto 17:39:14 [ morning break ] 17:39:23 rrsagent, draft minutes 17:39:23 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz 17:39:55 -> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0 high level use case spreadsheet 18:05:23 scribenick: ted 18:22:46 [discussion recalling use cases from Bart @@@ of the Netherlands, emergency responders wanting to know locations of and/or ability to disabled air bags] 18:26:31 http://www.w3.org/2015/07/vehicle-data#idl-def-AirbagStatus 18:32:35 paul: this use case exercise will also be useful in discovering omissions in data spec 18:38:02 ivan: the data polling frequency is extensive 18:39:12 paul: some like traction control systems and oil pressure you want to know immediately 18:39:41 ... it is also possible to have a bad data reading and those should be discarded 18:40:12 ... there is monitoring for events which requires storing values and computing to calculate changes 18:41:00 ... subscribing is polling for all data and determining when an event happens. separately we want a better event listener 18:41:18 dan: desire for a callback function 18:41:51 wonsuk: there are different approaches including callback. if the event happens we would want a handler 18:42:00 ... it is less expensive than polling 18:42:23 paul: we might want to add that to the spec 18:42:48 wonsuk: in case of battery status, you want to see the value changes and not a specific event 18:44:03 ... we have a subscription methodology, we will need to investigate others 18:44:38 kaz: we may want to have an extended version of subscribe which notices a significant change from previous poll 18:45:28 ted: i agree a listener would be advantageous and less expensive to developer but that requires processing upstream to trigger event. will oem do? 18:47:29 kaz has joined #auto 18:47:48 ... i suspect many won't so i like extending subscription, cache of previous value, delta to consider change significant enough to act like a trigger and polling frequency to reduce cost when we are ok with checking every 10min instead of 10ms 18:47:55 https://github.com/w3c/automotive/issues/29 18:48:17 we did similar discussion recently. 18:49:44 greg: oem is not necessarily going to do the processing themselves or if they do willing to share 18:51:30 shinjiro: we already added duration to the subscribe method 18:51:43 ... we did not want to overly complicate the interface 18:52:09 ... i understand how setting a threshold would be useful as well 18:52:31 ... we leave that to implementation specific solutions 18:52:47 Zakim has left #auto 18:53:24 ... in case where battery is draining or tire wear increasing, people might want to be notified of delta event for a specific number 18:54:40 ... event listener effectively deprecates subscribe and feel we should keep with a simpler subscription function 18:54:59 kaz: are you opposed then to extending subscription further? 18:55:26 shinjiro: it is possible. kevron lobbied to keep the interface simple and i feel the same way 18:55:55 dan: if you pass a callback function, your specific logic could reside there 18:57:00 paul: you need two data elements, actual battery voltage and battery status is low 18:57:32 greg: if that low status level is an agreed threshold 18:58:40 dan: passing your threshold value and callback function is what i had in mind, it could be an average or current value 18:59:00 ivan: just send the data to the callback function and leave the logic to them 19:00:56 ... illustrated examples would be helpful 19:02:37 paul: are examples best within the spec or as a standalone document? 19:03:28 ted: concise examples should be included directly, collection of complex ones potentially split out and perhaps even published to an open repo where we can encourage their use and contributions 19:05:52 dan: i can see wanting a cloud based service or in car app running in the background detect the car is parked, it has started raining and closes the windows 19:08:09 paul: we went free form but we need to think about prioritization, which are candidates for further expansion etc 19:08:32 ... which are out of scope for our specs 19:09:46 ... spec was developed for on-board/in-car apps not external services although that is possible 19:10:37 dan: or a hybrid where data triggered by an event goes to an external service for evaluation, reporting and may send instruction back 19:10:49 [pause for lunch] 19:10:50 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html ted 20:40:29 junichi_ has joined #auto 20:41:20 paul suggests we review the use cases together to see if they make sense 20:41:49 greg: it would be good in doing so to make clear to the security&privacy tf how they should work on them 20:42:46 paul: yes, first pass should be if they are things we definitely can expose through the api, priority, how to expand them 20:43:02 ... we do not need to go full uml on them 20:43:46 ... genivi tends to do quite a bit of use case mapping and it can be useful. you should be able to write test cases based on these 20:44:02 ... end goal is to turn these into requirements for testing the spec 20:47:22 paul reads first one on wiping personal data on rental car 20:49:14 ted: it can perhaps be expanded to any shared vehicle situation, like borrowing a friend's car 20:49:34 dan: true but there may be some differences so maybe better to list separately 20:50:38 http://www.w3.org/2015/07/vehicle-data#personalization-interfaces 20:51:38 dan: clear contact information 20:51:45 paul: we don't do anything there 20:52:16 ted: could be something for the bg to take up because it certainly can be useful for apps to be able to access that 20:52:49 paul: this one can be expanded certainly 20:57:13 wonsuk has joined #auto 20:59:28 paul: i imagine the web runtime will not be active when the vehicle is off but cannot say that definitively, some may want to keep some background, low power capabilities 21:00:33 Dan has joined #auto 21:01:12 ted: there could be a signal sent (oem specific) to wake from suspend mode after which things can be queried 21:01:22 present+ Steve_Ohmert(OpenCar) 21:03:56 kaz: in that case, we need to identify the state/mode of the car and the web runtime 21:04:07 ... so we need some mechanism for that purpose 21:04:26 (regarding wake-up signal) 21:04:33 s/for that purpose/to manage the state and mode/ 21:05:22 kaz, we should perhaps raise this as an issue in gh 21:05:30 yeah 21:06:19 We may want to consider not only the mode of the car, but also the mode of the app. There may be things you want to allow the app to do in the background vs. foreground. 21:08:09 kaz_ has joined #auto 21:08:18 rrsagent, draft minutes 21:08:18 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_ 21:09:24 ISSUE: for remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application 21:09:24 Created ISSUE-1 - For remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application. Please complete additional details at . 21:14:30 off the topic. You may already but I found Genivi's vehicle web api reference implementation document. I though this might be good example for Testing Framework discussion because it mentions about data simulator and some test cases. 21:14:33 http://git.projects.genivi.org/?p=web-api-vehicle.git;a=blob_plain;f=doc/WebAPIforVehicleDataRI.pdf;hb=HEAD 21:15:42 junichi: we are looking at resource limits on vehicle and volume of data being processed 21:16:10 ... logging parts to cloud. some want real-time monitoring 21:16:43 ... it is necessary to monitor some sensitive data at least once a second 21:17:13 ... we are providing on-board terminal, user interface and server side systems 21:17:55 ... sever system is able to perform more calculations across specific and aggregate vehicle information 21:18:40 i|we are looking at|topic: Demo/Presentation by Sakamoto-san| 21:19:12 [review of project cycle - research, prototyping, inspection for mass production, mass production, improvement] 21:20:14 junichi: measurement to vehicle manufacturers, improve data workflow, ability to reproduce bugs and evaluate data 21:21:10 ... it can be significantly easier to update cars than issue costly recalls to fix bugs 21:22:17 ... there are several r&d teams at different organizations that are willing to share data 21:22:40 ivan: for reproducing bugs are you recording enough data to be able to reproduce the environment? 21:22:49 junichi: yes 21:23:31 [slide diagram of M2M architecture] 21:27:21 [slide on terminal system] 21:27:42 junichi: this system includes gps, 3g modules 21:28:21 ... we used a usb-can transceiver circuit with read-only capabilities 21:28:30 ... send function was disabled 21:28:44 [data filtering on terminal system] 21:29:40 junichi: we do filtering, re-sampling and data packaging 21:29:50 ivan: what do you mean by re-sampling? 21:30:40 junichi: combining like data 21:31:44 ... and sampling different parameters at different intervals 21:32:00 [html5 ui] 21:32:55 junichi: you can drag and drop items onto your dashboard. it also can show graph data over time 21:33:05 [demo starts] 21:33:42 junichi: you can drag and drop from list various parameters you want to keep track of 21:40:58 [discussion of local data storage capability and deferred upload when network connectivity is interrupted] 21:41:29 steve: following this remotely you would see it as delayed then? 21:41:33 junichi: correct 21:42:03 paul: what is the main use of this is for oems, to verify their design? 21:42:30 junichi: our system is for gathering real time data. there are separate tools for analysis 21:43:12 paul: do you use other devices other than vtc-100 with the can transceiver or are there other ways you can collect? 21:43:20 junichi: just the vtc-100 21:44:13 shinjiro: what sort of typical time delay for following? 21:44:26 junichi: 10ms, usually worst is 1s 21:44:36 paul: you can guarantee the network? 21:44:42 [laughter] 21:44:54 junichi: i cannot guarantee the network 21:45:25 ... we tried this at a large test track in germany with mountains obstructing cell signal 21:46:05 ... we reduce the size of the packets to be transmitted as small as possible so we can get the payload out when we can, efficiently 21:46:24 greg: how are you securing the transmission? 21:46:36 junichi: https and device certification 21:47:09 ... right now we are providing the cloud portion of the service but it can be an organization's private cloud 21:47:25 steve: this is being used when oem is testing vehicles 21:47:46 ... are there any wanting to deploy this is production vehicles for real world data sampling? 21:48:04 junichi: yes. many are already doing telematics data gathering 21:48:45 ... but typically their data sampling rate is too low 21:49:27 s/at a large test track in germany/Nürburgring, at a large test track in germany,/ 21:50:09 ... server is able to detect some dangerous situations and report back to the user 21:50:22 paul: this seems like an area vector might be interested in 21:50:28 junichi: they are partnering 21:51:06 steve: the exi discussion yesterday from agile seems pertinent 21:52:00 ivan: did you create the interfaces yourself? 21:52:07 junichi: yes and all in html5 21:52:13 s/agile/AgileDelta/ 21:52:52 ... we are using binary data format 21:53:04 shinjiro: which, something like exi? 21:53:12 junichi: no, proprietary 21:54:32 Topic: Presentation from Steve Ohmert 21:55:24 steve: i'll review our architecture in brief and security considerations 21:55:40 ... we went through an outside review and certification 21:56:22 s/Topic: Presentation from Steve Ohmert/Topic: Presentation from Steve Ohmert on OpenCar Security/ 21:57:26 steve: we are a html5 solution. this application framework shows the different levels, web runtime, localhost capabilities 21:57:43 [slide of all the components] 21:59:24 steve: we isolate all the different layers and applications, similarly control all connectivity in and out 22:00:07 ... we need to make sure everything is coming from our system, going through our gateway 22:00:24 ... the browser runtime only talks to our local server 22:00:44 ... the host layer handles all external connections 22:01:22 [diagram on connectivity] 22:01:33 steve: we make use of html5 web workers 22:02:00 ... actually we have several different models but in this diagram it is web workers and iframe 22:02:47 ... iframe is separated at dom level. we isolate with content security policy (csp) 22:03:06 ... the applications are only allowed to communicate through a message pipe 22:03:19 ... we keep the message communication constrained 22:04:59 ... gateway, rest server, logic layer that restricts specific data access permisssions 22:07:43 ... what sorts of concerns are you hearing? what security issues are you hearing? 22:08:08 dan: we are defining parties and what data they can get at. most things are explicitly read only 22:08:31 steve: we have two ways of addressing that in our system. anything going into the car is certified and embedded 22:10:16 ... we have policies on which information is accessible to specific applications. we also generally expose things for read access 22:10:45 dan: who grants permissions for applications? 22:11:04 steve: the publisher includes in their package manifest what they are seeking access to 22:12:07 hashimoto: how do you handle the app install? 22:12:38 steve: package is download, checksums verified and then installed to run locally 22:13:19 hashimoto: it sounds similar to firefox os model 22:21:24 kaz: question about the interface between the integration layer and component modules via websocket 22:21:38 steve: @@@ 22:21:42 Hirabayashi has joined #auto 22:23:12 paul: explains OpenCar's downloadable version of SDK 22:25:40 steve: separation of HMI and app logic 22:30:38 ... security concerns with downloadable apps? 22:32:55 ivan: you could send data to the headunit to open the door 22:33:51 steve: you need to have separation mechanism 22:34:36 ... something has to say I have a permission 22:35:16 hira: how do you protect apps to be peeped? 22:35:48 steve: using a sandbox container is one level 22:36:00 ... construct a barrier is another 22:36:35 ... application should have access to various resources 22:37:26 ... certified permission only allow components to access some specific information 22:37:57 paul: also signed application 22:38:26 steve: this kind of mechanism is common with any downloadable apps 22:39:14 paul: permission from web runtime is not directly tied with the OS 22:40:28 steve: some constraint for integration 22:41:22 ... desire to allow JS to access low-level information is not a good idea 22:41:28 s/JS/JS codes/ 22:42:13 (thanks from all to Steve) 22:42:38 [ afternoon break ] 22:42:43 rrsagent, draft minutes 22:42:43 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_ 22:50:21 i/question about the/scribenick: kaz_/ 22:50:23 rrsagent, draft minutes 22:50:23 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_ 22:55:33 topic: Use Case discussion (revisited) 22:56:09 paul: we did much discussion on use cases during this f2f meeting 22:56:32 ... some same people should overview all the use cases 22:56:51 ... I will overview them 22:57:25 ... some others should also review them 22:57:41 ... issues should be tracked on GitHub 22:57:54 ... will do my review this week 22:58:30 ... Hashimoto-san should also do the review as the Security&Privacy TF moderator 22:58:59 ... what about Wonsuk as one of the Editors 22:59:40 wonsuk: we need to describe our use cases more clearly 22:59:55 ... also we need to describe our requirements 23:00:13 ... and then we can get feedback from others 23:01:09 ... should we add descriptions to the wiki? 23:01:22 paul: we got high level use case descriptions 23:01:54 ted: we can continue to use Google Docs for a while 23:02:09 paul: does that make sense? 23:02:13 wonsuk: yeah 23:02:40 paul: at some point we should be able to say "this is our scope" 23:02:55 ... would say less than one month 23:03:09 urata_access has joined #auto 23:03:21 dan: what is the criteria for prioritization? 23:04:19 paul: have some idea, put it on the wiki, and have discussion 23:04:34 ... we have two meetings 23:04:40 ... August 23:05:17 ... Asia friendly one and Europe friendly one 23:05:42 ... Aug. 4 one is in the morning in Asia 23:06:48 wonsuk: can't make it 23:07:03 paul: should be better to make 1 hour later? 23:08:47 ... does the security&privacy tf have regular calls? 23:08:50 hashimoto: no 23:09:01 ... holding email discussions 23:09:16 paul: next Tuesday we'll talk about use cases 23:09:48 ... if you guys (security&privacy tf) can talk with each other beforehand, would be good 23:10:12 ... can talk about prioritization 23:10:39 ... have a lit of topics 23:10:44 ... will send it to the group 23:11:17 ACTION: Paul to send out the list of topics based on the f2f discussion to the group 23:11:17 Created ACTION-9 - Send out the list of topics based on the f2f discussion to the group [on Paul Boyes - due 2015-08-05]. 23:11:29 paul: will talk about ISSUE-37 as well 23:11:45 ... can you lead the discussion, Wonsuk? 23:12:23 ... you can respond to the GitHub issue 37 23:13:01 ... got no response from TAG yet 23:13:15 wonsuk: pros/cons of each method 23:13:31 paul: Urata-san also should be involved 23:13:55 ... that's pretty much what I remember 23:14:53 kaz: wanted to double check the Aug. 4 slot 23:14:57 ... 5pm Pacific? 23:15:02 paul: yes 23:15:10 ... will send an announcement to the group 23:17:32 kaz: another topic I wanted to mention was demo showcase during TPAC 2015 in Sapporo 23:18:37 ted: should forward the announcement to the group list 23:18:44 kaz: ok, maybe the Member list 23:19:42 hira: question on user identification 23:19:57 paul: have a list of issues including that 23:20:06 ... will send a message to the group 23:20:13 ... we can add issues on GitHub 23:20:21 ... probably 5-6 issues 23:20:26 hira: ok 23:20:42 greg: onborad vs offboard 23:21:02 ivan: electric vehicle and hybrid vehicle? 23:21:22 ... just curious 23:22:03 greg: in the battery section 23:22:26 ted: trying to get those automakers as well 23:22:45 paul: can we invite them to one of our meetings? 23:24:49 (some discussion on related stakeholders) 23:25:22 paul: maybe you (those don't participate in the WG yet) can join the BG as well 23:26:10 ... next f2f meeting on Monday/Tuesday (Oct. 26/27) in Sapporo 23:26:39 ted: tx to Paul and OpenCar :) 23:27:19 rrsagent, draft minutes 23:27:19 I have made the request to generate http://www.w3.org/2015/07/29-auto-minutes.html kaz_