IRC log of auto on 2016-06-08

Timestamps are in UTC.

00:00:37 [RRSAgent]
RRSAgent has joined #auto
00:00:37 [RRSAgent]
logging to
00:00:40 [ted]
scribenick: ted
00:00:47 [PowellKinney]
PowellKinney has joined #auto
00:01:59 [ted]
Present+ Junichi, Paul, Powell, Kevin, Rudi, Ted
00:03:10 [kaz]
kaz has joined #auto
00:04:12 [ted]
Present+ Dave, Urata, Song
00:04:28 [ted]
Topic: Draft spec review
00:04:54 [AdamC]
AdamC has joined #auto
00:04:54 [urata_access]
urata_access has joined #auto
00:04:54 [ted]
Paul: the main topic should be spec, we can get into F2F logistics or other topics if they wish
00:04:59 [ted]
Present+ Adam
00:05:53 [ted]
-> draft spec
00:06:01 [kaz]
rrsagent, draft minutes
00:06:01 [RRSAgent]
I have made the request to generate kaz
00:06:22 [kaz]
rrsagent, make log public
00:06:24 [kaz]
rrsagent, draft minutes
00:06:24 [RRSAgent]
I have made the request to generate kaz
00:06:46 [kaz]
present+ Kaz
00:07:22 [kaz]
00:07:35 [kaz]
agenda+ WG Charter Extension
00:07:43 [ted]
Adam: basically we took Powell's suggestion of having json structure of the request itself, added oauth tokens
00:09:25 [ted]
… initialization of websocket. we have it set as localhost for now
00:09:37 [ted]
… in terms of uri schemes we are mandating wss initiated over https
00:09:56 [ted]
… we wanted to discuss a few things like whether we can reserve ports
00:11:32 [ted]
Kevin: some may argue to allow either ws or wss given thoughts the vehicle network may be considered secure. the trend is to secure more on vehicle networks
00:11:59 [ted]
… we are passing security tokens around and those could be sniffed and intercepted
00:12:23 [ted]
… attacker can get onto vehicle and escallate the intrusion
00:12:36 [ted]
… also motivation behind having timeout on tokens
00:12:46 [ted]
… best to start more secure from the beginning
00:13:09 [ted]
Adam: we send json blob to the server with action and path
00:13:35 [ted]
… it can be basic or more detailed. action can be get/set subscribe or unsubscribe
00:13:53 [ted]
… subscription can be either interval (time lapse) or onchange
00:14:44 [ted]
… onchange can be set to true or with boundaries eg temp changes 10 degrees C or speed jumps 10km/h
00:15:09 [ted]
… service will provide an id, handle to itself
00:15:39 [ted]
… we give response code along with json response
00:16:42 [ted]
Kevin: reason to have number and error code, you may get an authentication issue for example or request is otherwise invalid
00:17:16 [ted]
Adam: with the subscribe are another set of options you can set
00:17:33 [ted]
… following VSS route with the path naming
00:17:58 [ted]
… server will return id handle along with json
00:18:24 [ted]
Kevin: Rudi asked if it would be better for the client to provide the id. this way seems more natural
00:19:04 [ted]
[avoids client making mistake asking for an already used socket]
00:19:05 [PowellKinney]
00:19:41 [ted]
Kevin: client needs to be careful to avoid making duplicate subscriptions
00:20:18 [ted]
Adam: authentication can be user level or device level
00:20:34 [ted]
Rudi: my original idea was to have client side and server side id
00:21:07 [ted]
… comparing the path and other parameters could work too
00:21:20 [ted]
Powell: what we want is the client to specify an id
00:21:35 [ted]
… the one web socket might be shared by multiple clients
00:22:28 [ted]
… i am of the opinion there should be something unique from the client side
00:22:34 [kaz]
q+ to ask where to install the certificate and who to manage it (later)
00:23:50 [ted]
Kevin: a client would normally create one web socket although that is not mandated
00:24:49 [ted]
… the server can guarantee that each socket is unique
00:25:41 [ted]
… the server echoing back enough of the parameters will make it feasible for the client to map and manage its sockets
00:27:19 [ted]
Powell: these are transactional but not stateful. i may send a number of get requests and need to know which is being responded to
00:27:53 [ted]
Kevin: if a client creates a given web socket connection that instance is tied to a different object in your code, right?
00:28:20 [ted]
… client can keep them straight based on the reponse and id given from the server
00:28:37 [kaz]
00:28:44 [ted]
Powell: you may be right, you might be able to only get one connection per port
00:29:16 [ted]
Adam: if we use Oauth2 we can send the token with the request
00:29:37 [ted]
Kevin: the concept here is there are basically two different things with authentication
00:29:47 [PowellKinney]
s/transactional but not stateful/stateful but not transactional/
00:30:09 [ted]
… we may want to authenticate a user or device (vehicle or another off board)
00:30:59 [ted]
… ECU may have different priviledges
00:31:34 [ted]
… signals that are not under access control would not need to send token as part of their request
00:32:27 [ted]
Adam: onchange obviously is more simple in the discrete case
00:32:40 [ted]
… default is true, to receive message when the signal changes
00:34:24 [ted]
… we can specify min and max change parameters to limit what we wish to follow
00:35:41 [ted]
… following VSS path you can subscribe to different areas (engine for instance)
00:36:40 [ted]
Kevin: you can subscribe to individual signals of different types with different intervals or same signal multiple times
00:37:20 [ted]
Adam: under engine you can set interval since trying to get all that on every change would be too much
00:37:49 [ted]
Kevin: change can minimize volume as well
00:38:23 [ted]
… we want the client to specify interval they are interested in instead of one mandated by the server
00:38:24 [ted]
00:40:40 [ted]
00:41:17 [ted]
Ted: the client might request a frequency interval that the server is unable or unwilling to provide. the response could have the alternate interval
00:41:36 [ted]
Kevin: that is a possibility. at present we are inclined to decline the request
00:42:14 [ted]
Ted: in that case an error code indicating frequency is too high
00:42:54 [ted]
Kevin: that could work, client could then handle and retry at a different interval. if the server is overloaded it might want to defer in the same manner
00:43:48 [ted]
Adam: we have a number of restful error messages already
00:44:18 [ted]
… if the information isn't valid for that vehicle
00:45:14 [ted]
… regarding lifecycle of the web socket, the server reserves the right to close the connection
00:46:31 [ted]
[Adam going over example in spec with engine.tps boundaries]
00:46:41 [hira]
hira has joined #auto
00:47:30 [ted]
Kevin: you can choose to not have a min change and just a max one. we are also considering range
00:48:06 [ted]
… there are a couple ways we can go. for the moment it is either above or below respective max and min
00:48:12 [kaz]
present+ Hirabayashi
00:51:15 [ted]
Adam: you can send id of the socket you want to unsubscribe to or 0 for all your connections
00:52:09 [ted]
Ted wonders about how server could keep track of the different clients and their connections so as not to close the others. unsubscribe is worthwhile but you can also close web socket without unsub
00:53:55 [ted]
Kevin: a client should be able to unsubscribe all its connections
00:54:35 [ted]
Rudi: sounds like a server implementation detail
00:54:52 [kaz]
00:55:58 [ted]
Powell reports on testing multiple sockets from same client
00:58:35 [ted]
Kevin: you can potentially have a race condition if two sockets try to send the same change request
00:58:53 [ted]
… you will end up with last update winning and dirty reads
00:59:21 [ted]
Adam: here (sharing screen walthrought of spec) are all the get/set options
00:59:30 [ted]
… there are some more complex types you can subscribe to
01:00:09 [ted]
… if for example you request all doors with wildcard you will get back an array instead of single json blob
01:00:45 [ted]
… if you request data that doesn't exist you'll get back unrecognized message
01:01:15 [ted]
… you can send a set lock command to all doors in the same manner
01:01:33 [ted]
… values we cannot set will get a denied error message
01:01:56 [ted]
… if you try to set lock on engine you'll get back unsupported
01:02:50 [ted]
Kevin: subscriptions are expensive for the server and may need to fine tune them
01:03:12 [ted]
… there is not much point in giving an id on simple get
01:03:33 [ted]
Powell: the idea that there is no transactional layer here so we need to add some
01:03:56 [ted]
… each get should have some sort of transactional reference (request id) so i know which one is responding
01:04:27 [ted]
Kaz: the lifecycle of socket connection depends on transaction layer
01:05:00 [ted]
Kevin: if you are going to allow getting multiple signals, how are you going to decide the unique id?
01:05:30 [ted]
… perhaps based on request path
01:05:38 [ted]
Kaz: the two levels are transaction and server
01:05:59 [kaz]
01:06:01 [ted]
Powell: it is possible a connection is lost (or closed) so want to know which one is responding
01:06:06 [kaz]
s/server/whole application-wide/
01:07:05 [ted]
Kevin: we considered having timestamp as part of the response so you can have some idea of ordering (if you get responses out of order)
01:07:15 [ted]
… that stamp could be the request stamp
01:07:25 [ted]
s/request stamp/request timestamp/
01:08:53 [ted]
… we are continuing to add to the draft
01:10:10 [ted]
Paul does time check and sees if anyone has comments on security aspects so far
01:10:15 [kaz]
01:10:19 [kaz]
ack k
01:10:19 [Zakim]
kaz, you wanted to ask where to install the certificate and who to manage it (later) and to
01:10:24 [ted]
Song: I'll read further and send on mail list
01:10:41 [kaz]
01:11:18 [ted]
Junichi: I will send more to the list too
01:12:00 [ted]
Kaz: we need to start a discussion by email on extending the charter
01:16:10 [ted]
Kaz will ask Philipp to bring a 3 month extension to W3M. We will have a better sense of scope and timeline of work at F2F in July for a recharter
01:16:12 [RRSAgent]
I have made the request to generate ted
01:17:12 [kaz]
s/W3M./W3M. We will update the WG Charter based on the TF discussions./
01:17:16 [kaz]
rrsagent, draft minutes
01:17:16 [RRSAgent]
I have made the request to generate kaz
01:20:47 [ted]
RRSAgent, bye
01:20:47 [RRSAgent]
I see no action items