Merge remote-tracking branch 'upstream/develop' into 53177

85 files changed, 2670 insertions, 1805 deletions

diff --git a/BUILD.md b/BUILD.md
index 436d64c..d7367e6 100644
--- a/BUILD.md
+++ b/BUILD.md
@@ -1,3 +1,9 @@
+<style type="text/css" media="print">
+  div.pagebreak
+  {
+    page-break-before: always;
+  }
+</style>
 Copyright (C) 2014-2016, Jaguar Land Rover
 
 This document is licensed under Creative Commons
@@ -35,6 +41,10 @@ Please note that the configuration process described in
 2. The user can gain root access to install packages.
 3. There is at least 5GB of space availabled for packages and code.
 
+----
+
+<div class="pagebreak"></div>
+
 # INSTALLATION PROCESS #
 
 ## INSTALL DEVELOPMENT TOOLS ##
@@ -78,6 +88,8 @@ to the build system.
 
 The clone will be downloaded into a newly created ```rvi_core``` subdirectory.
 
+----
+
 ## BUILD THE RVI SYSTEM ##
 
 Run ```make``` to build the dependency code in ```deps``` and the
@@ -87,7 +99,9 @@ top level project in the ```rvi``` directory.
 
 The local ```rebar``` command is used to retrieve the dependencies. See
 ```rebar.config``` and ```deps/*/rebar.config``` for a list of
-dependencies. 
+dependencies.
+
+<div class="pagebreak"></div>
 
 See the [rebar](https://github.com/basho/rebar) project for a detailed
 description of the rebar Erlang build tool.
diff --git a/CONFIGURE.md b/CONFIGURE.md
index 9364ba3..d5cb540 100644
--- a/CONFIGURE.md
+++ b/CONFIGURE.md
@@ -1,3 +1,9 @@
+<style type="text/css" media="print">
+  div.pagebreak
+  {
+    page-break-before: always;
+  }
+</style>
 Copyright (C) 2014-2016, Jaguar Land Rover
 
 This document is licensed under Creative Commons
@@ -19,15 +25,13 @@ The reader is assumed to be able to:
 3. Edit configuration files.
 4. Understand the basic concepts of IP addresses, ports and URLs.
 
-
 ## PREREQUISITES
 
 1. Erlang runtime 18.2 or later has to be installed on the hosting system.
-2. The ```setup_rvi_node.sh``` tool is available to build a release.
-3. ```rvi_sample.config``` is used as a starting point for a customized setup.
+2. The `setup_rvi_node.sh` tool is available to build a release.
+3. `rvi_sample.config` is used as a starting point for a customized setup.
 Root access is not needed.
 
-
 ## CONFIGURATION PROCESS OVERVIEW
 
 To bring up an RVI node so that it can be used by locally
@@ -58,12 +62,12 @@ have their URLs configured so that the components can locate each
 other and exchange commands.
 
 <b>6. Build the development release</b><br>
-The ```setup_rvi_node.sh``` script is executed to read the configuration file
+The `setup_rvi_node.sh` script is executed to read the configuration file
 and generate a development or production release.
 
 <b>7. Start the release</b><br>
-The ```rvi_node.sh``` script is executed to launch the built development
-release. ```$REL_HOME/rvi/bin/rvi start``` is used to launch the
+The `rvi_node.sh` script is executed to launch the built development
+release. `$REL_HOME/rvi/bin/rvi start` is used to launch the
 production release.
 
 
@@ -71,13 +75,13 @@ production release.
 
 There is a single configuration file, with the setup for all
 components and modules in the node, used for each release. 
-A documented example file is provided as ```priv/config/rvi_sample.config```
+A documented example file is provided as `priv/config/rvi_sample.config`
 
 The configuration file consists of an array of erlang tuples (records
-/ structs / entries), where the ```env``` tuple contains configuration data for
-all components. The ```rvi``` tuple under ```env``` has all the
+/ structs / entries), where the `env` tuple contains configuration data for
+all components. The `rvi` tuple under `env` has all the
 configuration data for the RVI system. With the possible exception for
-the lager logging system, only the ```rvi``` tuple needs to be edited.
+the lager logging system, only the `rvi` tuple needs to be edited.
 
 The term tuple and entry will be intermixed throughout this document.
 
@@ -85,9 +89,9 @@ The term tuple and entry will be intermixed throughout this document.
 
 For a full description of Erlang types, read [the Erlang Reference Manual](http://erlang.org/doc/reference_manual/users_guide.html). The following is a brief summary:
 
-* Tuples, written as ```{ Elem1, ..., ElemN }``` are like arrays whose elements are accessed by position.
-* Lists, written as ```[ Elem1, ..., ElemN ]``` are linked lists whose elements are accessed by iterating from the beginning of the list. Another notation is ```[ Head | Tail ]```. Strings are actually lists of integers, and ```"RVI"``` is equivalent to ```[82,86,73]```, or ```[$R,$V,$I]```.
-* Numbers, e.g. ```17```, ```1.44```, ```2#101``` (binary notation), ```16#5A``` (hex notation).
+* Tuples, written as `{ Elem1, ..., ElemN }` are like arrays whose elements are accessed by position.
+* Lists, written as `[ Elem1, ..., ElemN ]` are linked lists whose elements are accessed by iterating from the beginning of the list. Another notation is `[ Head | Tail ]`. Strings are actually lists of integers, and `"RVI"` is equivalent to `[82,86,73]`, or `[$R,$V,$I]`.
+* Numbers, e.g. `17`, `1.44`, `2#101` (binary notation), `16#5A` (hex notation).
 * Atoms, names starting with a lowercase letter or enclosed in single quotes, are essentially labels.
 * Variable names start with an uppercase letter.
 
@@ -95,10 +99,10 @@ For a full description of Erlang types, read [the Erlang Reference Manual](http:
 
 RVI Core uses the [setup](https://github.com/uwiger/setup) tool to build from configuration files.
 
-The files used by ```setup``` are evaluated using the [file:script/1](http://erlang.org/doc/man/file.html#script-1) function, meaning that the file can contain a sequence of executable Erlang expressions, each terminated with a full stop (```.```). Anything starting with ```%``` and to the end of the line
+The files used by `setup` are evaluated using the [file:script/1](http://erlang.org/doc/man/file.html#script-1) function, meaning that the file can contain a sequence of executable Erlang expressions, each terminated with a full stop (`.`). Anything starting with `%` and to the end of the line
 constitutes a comment.
 
-Example from ```rvi_core/priv/config/rvi_sample.config```:
+Example from `rvi_core/priv/config/rvi_sample.config`:
 
     Env = fun(V, Def) ->
                   case os:getenv(V) of
@@ -118,21 +122,23 @@ Example from ```rvi_core/priv/config/rvi_sample.config```:
     BackendPort = Env("RVI_BACKEND_PORT", 8807).
     LogLevel = Env("RVI_LOGLEVEL", notice).
 
-The above defines two function objects used to check for the existence of a given OS environment variable, and using the corresponding value, or else using a default value. For example, the variable ```MyPort``` is set to either the value of ```RVI_PORT``` or else to ```9000```. These variables are used further down in the configuration file.
+The above defines two function objects used to check for the existence of a given OS environment variable, and using the corresponding value, or else using a default value. For example, the variable `MyPort` is set to either the value of `RVI_PORT` or else to `9000`. These variables are used further down in the configuration file.
+
+<div class="pagebreak"></div>
 
-The ```setup``` utility is called when the ```rvi.sh``` script is run. To e.g. enable debug logging, you can do the following:
+The `setup` utility is called when the `rvi.sh` script is run. To e.g. enable debug logging, you can do the following:
 
     $ RVI_LOGLEVEL=debug rvi.sh ...
 
-```Setup``` expects certain configuration entries, e.g. ```{apps, [App1, ...]}```, ```{env, [{App, [{Key, Val}, ...]}, ...]}```. Most of the configuration work for RVI is done in ```{env, ...}```.
+`Setup` expects certain configuration entries, e.g. `{apps, [App1, ...]}`, `{env, [{App, [{Key, Val}, ...]}, ...]}`. Most of the configuration work for RVI is done in `{env, ...}`.
 
-It is possible to include existing configuration files and then modifying the result. For example, the ```rvi_sample.config``` file includes ```rvi_core/priv/config/rvi_common.config``` via the following line:
+It is possible to include existing configuration files and then modifying the result. For example, the `rvi_sample.config` file includes `rvi_core/priv/config/rvi_common.config` via the following line:
 
      {include_lib, "rvi_core/priv/config/rvi_common.config"},
 
-Includes can be used at several levels. For example, ```priv/test_config/basic_backend.config``` includes ```priv/test_config/backend.config```, which in its turn includes ```priv/config/backend.config```, which, finally, includes ```priv/config/rvi_common.config```.
+Includes can be used at several levels. For example, `priv/test_config/basic_backend.config` includes `priv/test_config/backend.config`, which in its turn includes `priv/config/backend.config`, which, finally, includes `priv/config/rvi_common.config`.
 
-Other examples can be found in ```rvi_core/priv/test_config/```, where configurations used by the test suite are located:
+Other examples can be found in `rvi_core/priv/test_config/`, where configurations used by the test suite are located:
 
     {ok, CurDir} = file:get_cwd().
     [
@@ -146,7 +152,9 @@ Other examples can be found in ```rvi_core/priv/test_config/```, where configura
       ]}
     ].
 
-The ```set_env``` instruction specifically takes a list of ```{App, [{Key, Value}]}``` tuples, where the ```Key``` is either an atom or list of atoms, the latter indicating an entry in a 'tree' of entries. In the example above, the tree would look like:
+<div class="pagebreak"></div>
+
+The `set_env` instruction specifically takes a list of `{App, [{Key, Value}]}` tuples, where the `Key` is either an atom or list of atoms, the latter indicating an entry in a 'tree' of entries. In the example above, the tree would look like:
 
     {rvi_core,
      [
@@ -172,10 +180,10 @@ The ```set_env``` instruction specifically takes a list of ```{App, [{Key, Value
 
 If the entry in question exists in the tree, it will be modified; if not, it will be added.
 
-For more details about what can be done with ```setup```, see (the setup_gen manual)[https://github.com/uwiger/setup/blob/master/doc/setup_gen.md].
+For more details about what can be done with `setup`, see (the setup_gen manual)[https://github.com/uwiger/setup/blob/master/doc/setup_gen.md].
 
 ## CONFIGURATION FILE VALUE SUBSITUTION
-Some forms of substitution are supported by ```setup```, see (the docs on variable expansion)[https://github.com/uwiger/setup/blob/master/doc/setup.md#Variable_expansion].
+Some forms of substitution are supported by `setup`, see (the docs on variable expansion)[https://github.com/uwiger/setup/blob/master/doc/setup.md#Variable_expansion].
 
 RVI Core supports some additional substitution of its own. All substitution is done automatically when RVI starts, so the running applications see the final results of the substitutions.
 
@@ -184,53 +192,55 @@ for specific dokens during startup. If a token is
 found, it will be replaced with a value referenced by it.
 Tokens can one of the following:
 
-* ```$rvi_file(FileName,Default)``` - File content<br>
-  When an ```$rvi_file()``` token is encountered, the first line of
+* `$rvi_file(FileName,Default)` - File content<br>
+  When an `$rvi_file()` token is encountered, the first line of
   the referenced file is read. The line (without the newline)
   replaces the token.<br>
   Example:<br>
-  ```{ node_service_prefix, "jlr.com/vin/$rvi_file(/etc/vin,default_vin)"}```
+  `{ node_service_prefix, "jlr.com/vin/$rvi_file(/etc/vin,default_vin)"}`
 
   will be substituted with the first line from the
-  file ```/etc/vin```:
+  file `/etc/vin`:
 
-  ```{ node_service_prefix, "jlr.com/vin/2GKEG25HXP4093669"}```
+  `{ node_service_prefix, "jlr.com/vin/2GKEG25HXP4093669"}`
   
-  If ```/etc/vin``` cannot be opened, the value ```default_vin```
+  If `/etc/vin` cannot be opened, the value `default_vin`
   will be used instead.
 
-* ```$rvi_env(EnvironemtnName,Default)``` - Environment variable<br>
-  When an ```$rvi_env()``` token is encountered, the value of 
+<div class="pagebreak"></div>
+
+* `$rvi_env(EnvironemtnName,Default)` - Environment variable<br>
+  When an `$rvi_env()` token is encountered, the value of 
   the Linux process environment variable (such as $HOME) is read
   to replace the token.<br>
 
   Example:<br>
-    ```{ node_service_prefix, "jlr.com/vin/$rvi_env(VIN,default_vin)"}```
+    `{ node_service_prefix, "jlr.com/vin/$rvi_env(VIN,default_vin)"}`
 
-    will be substituted with the value of the ```$VIN``` environment
+    will be substituted with the value of the `$VIN` environment
     variable:
 
 
-    ```{ node_service_prefix, "jlr.com/vin/2GKEG25HXP4093669"}```
+    `{ node_service_prefix, "jlr.com/vin/2GKEG25HXP4093669"}`
   
     If VIN is not a defined environment variable, the value
-    ```default_vin``` will be used instead.
+    `default_vin` will be used instead.
 
-* ```$rvi_uuid(Default)``` - Unique machine identifier<br>
-  When an ```$rvi_uuid()``` token is encountered, the UUID of the root
+* `$rvi_uuid(Default)` - Unique machine identifier<br>
+  When an `$rvi_uuid()` token is encountered, the UUID of the root
   disk used by the system is read to replace the token.
-  The UUID of the root disk is retrieved by opening ```/proc/cmdline```
-  and extracting the ```root=UUID=[DiskUUID]``` value.
+  The UUID of the root disk is retrieved by opening `/proc/cmdline`
+  and extracting the `root=UUID=[DiskUUID]` value.
   This value is generated at system install time and is reasonably
   world wide unique.
 
   Example:<br>
-    ```{ node_service_prefix, "jlr.com/vin/$uuid(default_vin)"}```
+    `{ node_service_prefix, "jlr.com/vin/$uuid(default_vin)"}`
 
   will be substituted with the value of the root disk UUID:
-    ```{ node_service_prefix, "jlr.com/vin/afc0a6d8-0264-4f8a-bb3e-51ff8655b51c"} ```
+    `{ node_service_prefix, "jlr.com/vin/afc0a6d8-0264-4f8a-bb3e-51ff8655b51c"} `
   
-  If the root UUID cannot be retrieved, the value ```default_vin```
+  If the root UUID cannot be retrieved, the value `default_vin`
   will be used instead.
 
 # SPECIFY NODE SERVICE PREFIX #
@@ -257,21 +267,23 @@ prefix identifying what their role is.
 
 Below are a few examples of prefixes:
 
-```jaguarlandrover.com/vin/sajwa71b37sh1839/``` - A JLR vehcile with
+`jaguarlandrover.com/vin/sajwa71b37sh1839/` - A JLR vehcile with
 the given vin.<br>
 
-```jaguarlandrover.com/mobile/+19492947872/``` - A mobile device with
+`jaguarlandrover.com/mobile/+19492947872/` - A mobile device with
 a given number, managed by JLR, hosting an RVI node.<br>
 
-```jaguarlandrover.com/sota/``` - JLR's global software over the air
+`jaguarlandrover.com/sota/` - JLR's global software over the air
 server.<br>
 
-```jaguarlandrover.com/3rd_party/``` - JLR's 3rd party application
+`jaguarlandrover.com/3rd_party/` - JLR's 3rd party application
 portal.<br>
 
-```jaguarlandrover.com/diagnostic/``` - JLR's diagnostic server.<br>
+`jaguarlandrover.com/diagnostic/` - JLR's diagnostic server.<br>
 
-The prefix for an RVI node is set in the ```node_service_prefix``` tuple.
+The prefix for an RVI node is set in the `node_service_prefix` tuple.
+
+<div class="pagebreak"></div>
 
 An example entry is given below:
 
@@ -293,7 +305,6 @@ An example entry is given below:
 The following settings are required for the RVI Core authentication framework:
 
 * `{device_key, DevKeyFile}`
-* `{provisioning_key, ProvKeyFile}`
 * `{root_cert, RootCertFile}`
 * `{device_cert, DevCertFile}`
 * `{cred_dir, CredDirectory}`
@@ -310,7 +321,7 @@ The defaults should *only* be used for testing and demos - never for live use.
 
 #CONFIGURE DATA LINK LAYERS
 
-The ```data_link``` components are specified as ```{Module, Type, Options}```, e.g.
+The `data_link` components are specified as `{Module, Type, Options}`, e.g.
 
 <pre>
 [
@@ -328,7 +339,9 @@ The ```data_link``` components are specified as ```{Module, Type, Options}```, e
 ]
 </pre>
 
-In the data link component, ```dlink_tls_rpc```, you can specify the following options:
+<div class="pagebreak"></div>
+
+In the data link component, `dlink_tls_rpc`, you can specify the following options:
 
     { server_opts, Opts }
 
@@ -373,17 +386,18 @@ An example tuple is given below:
 ] 
 </pre>
 
-If ```dlink_tcp_rpc``` is to listen to the port on all network
-interfaces, the ```ip``` tuple can be omitted.
+If `dlink_tcp_rpc` is to listen to the port on all network
+interfaces, the `ip` tuple can be omitted.
    
 
-The ```persistent_connections``` section lists the IP:Port pair of all
+The `persistent_connections` section lists the IP:Port pair of all
 remote RVI nodes that this node should maintain a connection with. If the
 address is not available, a reconnection attempt will be made every five seconds.
 
 This allows a solid connection between RVI nodes where only one node can initiate
 a connection (such as a vehicle-to-server link in a mobile network).
 
+<div class="pagebreak"></div>
 
 # ROUTING RULES
 
@@ -391,7 +405,7 @@ Routing rules determining how to get a message targeting a specific
 service to its destination.
 
 A routing rule specifies a number of different way to reach an RVI
-node hosting a specific service prefix, such as ```jlr.com/vin/ABCD/sota/```.
+node hosting a specific service prefix, such as `jlr.com/vin/ABCD/sota/`.
 
 Please note that if a remotely initiated (== client) data link is
 available and has announced that the targeted service is available,
@@ -401,10 +415,10 @@ Service name prefix that rules are specified for
 The service prefix with the longest match against the service targeted
 by the message will be used.
 
-Example: Targeted service = ```jlr.com/backend/sota/get_updates```
+Example: Targeted service = `jlr.com/backend/sota/get_updates`
 
-Prefix 1: ```{ "jlr.com/backend", [...]}```<br>
-Prefix 2: ```{ "jlr.com/backend/sota", [...]}```<br>
+Prefix 1: `{ "jlr.com/backend", [...]}`<br>
+Prefix 2: `{ "jlr.com/backend/sota", [...]}`<br>
 
 In this case, Prefix 2 will be used. 
 
@@ -426,8 +440,8 @@ that it can handle the targeted service. Below is an example of a default rule.
 
 
 This rule specifies that, unless another rule has a longer prefix
-match, a request shall be encoded using ```proto_json_rpc```, and
-transmitted using ```dlink_tcp_rpc```.
+match, a request shall be encoded using `proto_json_rpc`, and
+transmitted using `dlink_tcp_rpc`.
 
 To direct an in-vehicle RVI-node to send all its backend requests to a
 specific address, add the following rule.
@@ -444,13 +458,15 @@ specific address, add the following rule.
 </pre>
 
 This rule specifies that any message to a service starting
-with ```jlr.com/backend``` shall first be encoded using ```proto_json_rpc```, 
-and transmitted using ```dlink_tcp_rpc```. The ```dlink_tcp_rcp``` data link
-module will be instructed to send all messages targeting ```jlr.com/backend/...``` to the
-IP-address:port ```38.129.64.31:8807```.
+with `jlr.com/backend` shall first be encoded using `proto_json_rpc`, 
+and transmitted using `dlink_tcp_rpc`. The `dlink_tcp_rcp` data link
+module will be instructed to send all messages targeting `jlr.com/backend/...` to the
+IP-address:port `38.129.64.31:8807`.
+
+<div class="pagebreak"></div>
 
 To setup Vehicle-to-Vehicle communication, where a vehicle can reach
-services on other vehicle's starting with ```jlr.com/vin/```, add the
+services on other vehicle's starting with `jlr.com/vin/`, add the
 following rule.
 
 <pre>
@@ -472,17 +488,17 @@ following rule.
 
 
 This rule specifies that any message to a service starting 
-with ```jlr.com/vin``` shall first be encoded using the protocol - data
-link pair ```proto_json_rpc``` - ```dlink_tcp_rpc```, where WiFi
-broadcasts shall be used (thrugh ```wlan0``` and ```broadcast```) to
+with `jlr.com/vin` shall first be encoded using the protocol - data
+link pair `proto_json_rpc` - `dlink_tcp_rpc`, where WiFi
+broadcasts shall be used (thrugh `wlan0` and `broadcast`) to
 find other vehiclces.
 
 If that does not work, a 3G connection to the vehicle shall be
-attempted, through the ```proto_json_rpc``` - ```dlink_3g_rpc``` pair,
+attempted, through the `proto_json_rpc` - `dlink_3g_rpc` pair,
 where we are allowed to initiate outbound connections to the 3G
 network in case a connection is not already available.
 
-Finally, an SMS can be sent through the ```proto_sms_rpc``` - ```dlink_sms_rpc``` pair,
+Finally, an SMS can be sent through the `proto_sms_rpc` - `dlink_sms_rpc` pair,
 maximizing message size to 140 bytes.
 
 
@@ -496,10 +512,12 @@ In cases where JSON-RPC is used instead of Erlang-internal gen\_server calls,
 other components in the RVI node use the same URL to send traffic
 to Service Edge
 
-The URL of Service Edge is specified through the ```service_edge_rpc```
-tuple's ```json_rpc_address``` entry, read by the other components in the node to
+The URL of Service Edge is specified through the `service_edge_rpc`
+tuple's `json_rpc_address` entry, read by the other components in the node to
 locate it.
 
+<div class="pagebreak"></div>
+
 An example entry is gven below:
 
 <pre>
@@ -530,7 +548,7 @@ An example entry is gven below:
 # SPECIFY URLS OF RVI COMPONENTS #
 The remaining components in an RVI system needs to have their URLs and
 listening ports setup as well.  It is recommended that consecutive
-ports after that used for ```service_edge_rpc``` are used.
+ports after that used for `service_edge_rpc` are used.
 
 Please note that if only erlang components are used (as is the case in
 the reference implementation), native erlang gen\_server calls can be
@@ -538,9 +556,10 @@ used instead of URLs, providing a significant transactional speedup. Please
 see the genserver components chapter below for details.
 
 Below is an example of a complete port/url configuration for all
-components, including the ```bert_rpc_server``` entry described in the
+components, including the `bert_rpc_server` entry described in the
 external node address chapter:
 
+<div class="pagebreak"></div>
 <pre>
 [
   ...
@@ -603,13 +622,13 @@ native erlang inter-process calls that are signficantly faster than
 JSON-RPC when transmitting large data volumes.
 
 If one or more of the RVI components are replaced with external
-components, use JSON-RPC by ```json_rpc_address```
+components, use JSON-RPC by `json_rpc_address`
 for all components.
 
 If an all-native erlang system is configured, use gen\_server calls
-by configuring ```gen_server```.
+by configuring `gen_server`.
 
-If both ```gen_server``` and ```json_rpc_address``` are specified, the
+If both `gen_server` and `json_rpc_address` are specified, the
 gen\_server communicaiton path will be used for inter component
 communication.
 
@@ -618,10 +637,10 @@ by this since data_link_bert_rpc will use the protocol and data links
 specified by the matching routing rule to communicate. See
 [Routing Rules](#ROUTING RULES) chapter for details.
 
-Below is an example of where gen\_server is used where approrpiate.
+Below is an example of where gen\_server is used where appropriate.
 
-Please note that ```service_edge_rpc``` always need to have
-its ```json_rpc_address``` specified since local services need an
+Please note that `service_edge_rpc` always need to have
+its `json_rpc_address` specified since local services need an
 HTTP port to send JSON-RPC to. However, gen\_server can still be
 specified in parallel, allowing for gen\_server calls to be made
 between Servie Edge and other RVI components.
@@ -666,13 +685,15 @@ between Servie Edge and other RVI components.
 ]
 </pre>
 
-# SETTING UP WEBSOCKET SUPPORT ON A NODE
+<div class="pagebreak"></div>
+
+# SETTING UP WEBSOCKET SUPPORT
 
 The service edge can, optionally, turn on its websocket support in order to
 support locally connected services written in javascript. This allows an RVI node
 to host services running in a browser, on node.js or similar web environments.
-Websocket support is enabled by adding a ```websocket``` entry to the configuration data
-of ```servide_edge_rpc```.
+Websocket support is enabled by adding a `websocket` entry to the configuration data
+of `servide_edge_rpc`.
 
 Below is the previous configuration example with such a setup.
 
@@ -699,7 +720,7 @@ Below is the previous configuration example with such a setup.
 
 
 Websocket clients can now connect to:
-```ws://127.0.0.1:8801/websession``` and issue JSON-RPC commands to
+`ws://127.0.0.1:8801/websession` and issue JSON-RPC commands to
 Service Edge. Outbound service invocations, sent from the RVI node to
 the javascript code, will be transmitted over the same socket.
 
@@ -728,23 +749,23 @@ Each release will have a name, which will also be the name of the
 newly created subdirectory containing the files necessary to start the
 release.
 
-If a configuration file, ```rvi_sample.config``` is to be used when building
-release ```test_rel```, the following command can be run from the
+If a configuration file, `rvi_sample.config` is to be used when building
+release `test_rel`, the following command can be run from the
 build root:
 
     ./scripts/setup_rvi_node.sh -d -n test_rel -c rvi_sample.config
 
 Once executed (and no errors were found in test.config), a
-subdirectory called ```test_rel``` has been created. This directory
+subdirectory called `test_rel` has been created. This directory
 contains the erlang configuration and boot files necessary to bring up
 the RVI node.
 
 # STARTING A DEVELOPMENT RELEASE
 
 The newly built development release is started using the
-```rvi_node.sh``` tool.
+`rvi_node.sh` tool.
 
-In order to start the test release, named ```test_rel```, created in
+In order to start the test release, named `test_rel`, created in
 the previous chapter, the following command is run from the build
 root:
 
@@ -764,27 +785,27 @@ Service Edge and start routing traffic.
 *Please note that a new release must be created each time the
  configuration file has been updated*
 
-To create a self contained production release using ```prod.config```
-as the configuration file, and name the release ```prod_rel```, the
+To create a self contained production release using `prod.config`
+as the configuration file, and name the release `prod_rel`, the
 following command can be run from the build root:
 
     ./script/setup_rvi_node.sh -n prod_rel -c prod.config
 
 Once executed (and no errors were found in test.config), a
-subdirectory called ```rel/prod_rel``` has been created. 
+subdirectory called `rel/prod_rel` has been created. 
 
-The ```prod_rel``` directory contains a complete erlang runtime
+The `prod_rel` directory contains a complete erlang runtime
 system, the RVI application, and the configuration data generated from
-```prod.config``` the RVI node.
+`prod.config` the RVI node.
 
-The ```prod_rel``` directory can be moved to anywhere in the file
+The `prod_rel` directory can be moved to anywhere in the file
 system, or to another host with the same architecture and OS setup.
 
 
 # STARTING A PRODUCTION RELEASE
 
 The newly built product release is started using the
-```rel/prod_rel/rvi``` tool:
+`rel/prod_rel/rvi` tool:
 
     ./rel/prod_rel/rvi start
 	
@@ -816,7 +837,7 @@ production release, and set the log level manually:
 	
 Replace debug with info, notice, warning, or error for different log
 levels. A production release will also produce logs to
-```rel/[release]/log/erlang.log.?```.
+`rel/[release]/log/erlang.log.?`.
 
 Check the file modification date to find which of the log files are
 currently written to.
diff --git a/Makefile b/Makefile
index 64ad34c..1c594cc 100644
--- a/Makefile
+++ b/Makefile
@@ -12,9 +12,31 @@
 
 .PHONY:	all deps compile clean rpm rpmclean test xref ci escript
 
+
 SCRIPTS=scripts/setup_gen \
 	scripts/author
 
+SRC_LIST=BUILD.md \
+	CONFIGURE.md \
+	doc \
+	LICENSE \
+	Makefile \
+	README.md \
+	rebar \
+	rebar.config \
+	rel \
+	RELEASE.md \
+	scripts/setup_gen \
+	scripts/rvi_ctl.template \
+	scripts/rvi_install \
+	python/*.py \
+	components \
+	priv \
+	ebin \
+	src \
+	deps \
+	TODO 
+
 VERSION=0.5.0
 
 all: deps compile escript
@@ -30,6 +52,7 @@ escript: compile ${SCRIPTS}
 recomp:
 	./rebar  compile skip_deps=true
 
+
 scripts/setup_gen: deps/setup/setup_gen
 	cp deps/setup/setup_gen scripts/
 
@@ -42,7 +65,13 @@ components/authorize/author:
 clean:   rpmclean
 	./rebar clean
 
-rpmclean:
+ubuntu_clean:
+	rm -rf ./ubuntu_build
+
+debian_clean:
+	rm -rf ./debian_build
+
+rpm_clean:
 	rm -rf ./rpm/BUILD/* \
 		./rpm/BUILDROOT/* \
 		./rpm/RPMS/* \
@@ -60,19 +89,74 @@ test: compile escript
 # Create a SOURCES tarball for RPM
 rpm_tarball: rpmclean clean
 	tar czf /tmp/rvi_core-$(VERSION).tgz BUILD.md CONFIGURE.md doc \
-		LICENSE Makefile README.md rebar rebar.config rel \
+		LICENSE Makefile README.md rebar rebar.config rel deps\
 		RELEASE.md rpm scripts/setup_gen scripts/rvi \
 		scripts/rvi.service scripts/rvi.sh \
 		components priv/config/rvi_sample.config scripts/rvi_instball.sh src \
-		TODO 
-	mv /tmp/rvi-$(VERSION).tgz ./rpm/SOURCES/
 
+# Create an ubuntu package 
+ubuntu_package: clean ubuntu_clean escript
+	install --mode=0755 -d ./ubuntu_build
 
-rpm:	rpm_tarball
+# Pack up all relevant files, and ubuntu/,  necessary for a build.
+# Add rvi-$(VERSION) at the beginning of each file so
+# that they get packed up into a correctly named subdirectory
+# 
+	tar czf ./ubuntu_build/rvi_$(VERSION).orig.tar.gz \
+		--exclude-vcs --transform="s|^|./rvi-$(VERSION)/|" \
+		$(SRC_LIST) \
+		ubuntu_template
+	rm -rf ubuntu/missing-sources
+# Unpack the created tar file
+	(cd ./ubuntu_build; tar xf rvi_$(VERSION).orig.tar.gz)
+# Move the ubuntu template to be the debian package
+	mv ./ubuntu_build/rvi-$(VERSION)/ubuntu_template  ./ubuntu_build/rvi-$(VERSION)/debian
+	install -d -m 0755 ./ubuntu_build/rvi-$(VERSION)/debian/missing-sources
+# Descend into the unpacked directory and build.
+	(cd ./ubuntu_build/rvi-$(VERSION); debuild -uc -us)
+
+# Create a debian package 
+debian_package: clean debian_clean escript
+	install --mode=0755 -d ./debian_build
+
+# Pack up all relevant files, and debian/,  necessary for a build.
+# Add rvi-$(VERSION) at the beginning of each file so
+# that they get packed up into a correctly named subdirectory
+# 
+	tar czf ./debian_build/rvi_$(VERSION).orig.tar.gz \
+		--exclude-vcs --transform="s|^|./rvi-$(VERSION)/|" \
+		$(SRC_LIST) \
+		debian_template
+	rm -rf debian/missing-sources
+# Unpack the created tar file
+	(cd ./debian_build; tar xf rvi_$(VERSION).orig.tar.gz)
+# Move the debian template to be the debian package
+	mv ./debian_build/rvi-$(VERSION)/debian_template  ./debian_build/rvi-$(VERSION)/debian
+	install -d -m 0755 ./debian_build/rvi-$(VERSION)/debian/missing-sources
+# Descend into the unpacked directory and build.
+	(cd ./debian_build/rvi-$(VERSION); debuild -uc -us)
+
+
+rpm:	rpmclean rpm_tarball 
 	rpmbuild --define "_topdir $$PWD/rpm" -ba rpm/SPECS/rvi-$(VERSION).spec
 
-install: # deps compile
-	./scripts/rvi_install.sh $(DESTDIR)/opt/rvi
-	install --mode=0755 -d $(DESTDIR)/etc/opt/rvi/
-	install --mode=0644 priv/config/rvi_sample.config $(DESTDIR)/etc/opt/rvi/rvi_sample.config
-	install --mode=0644 priv/config/rvi_common.config $(DESTDIR)/opt/rvi/rvi_core/rvi_common.config
+install: deps compile
+ifndef STRIPPATH
+	./scripts/rvi_install \
+		-k priv/keys/insecure_device_key.pem \
+		-r priv/certificates/insecure_root_cert.crt \
+		-d priv/certificates/insecure_device_cert.crt \
+		-c priv/credentials/insecure_credential.jwt \
+		$(DESTDIR)/opt/rvi_core
+else
+	./scripts/rvi_install \
+		-k priv/keys/insecure_device_key.pem \
+		-r priv/certificates/insecure_root_cert.crt \
+		-d priv/certificates/insecure_device_cert.crt \
+		-c priv/credentials/insecure_credential.jwt \
+		-s $(STRIPPATH) \
+		$(DESTDIR)/opt/rvi_core
+endif
+
+	install -m 0755 -d $(DESTDIR)/etc/opt/rvi/
+	install -m 0644 priv/config/rvi_sample.config $(DESTDIR)/etc/opt/rvi/rvi_sample.config
diff --git a/README.debian_build b/README.debian_build
new file mode 100644
index 0000000..8614727
--- /dev/null
+++ b/README.debian_build
@@ -0,0 +1,14 @@
+Erlang
+
+apt-get install devscripts
+apt-get install bluez
+apt-get install libbluetooth-dev 
+apt-get install git
+apt-get install g++
+apt-get install make
+apt-get install python-jsonrpclib
+apt-get install libwxgtk3.0-0
+apt-get install dh-systemd
+
+wget https://packages.erlang-solutions.com/erlang/esl-erlang/FLAVOUR_1_general/esl-erlang_18.2-1~debian~jessie_amd64.deb
+dpkg -i esl-erlang_18.2-1~debian~jessie_amd64.deb
diff --git a/README.md b/README.md
index 9a59005..1c1b405 100644
--- a/README.md
+++ b/README.md
@@ -20,11 +20,11 @@ Git branch management is JLR OSTCs standard git document
 
 For build instructions, please check the build instructions:
 [Markdown](BUILD.md) | 
-[PDF](https://wiki.automotivelinux.org/_media/eg-rvi/rvi-build.pdf)
+[PDF](doc/pdf/BUILD.pdf)
 
 For configuration and launch instructions, please check the configuration documentation:
 [Markdown](CONFIGURE.md) | 
-[PDF](https://wiki.automotivelinux.org/_media/eg-rvi/rvi-configure.pdf)
+[PDF](doc/pdf/CONFIGURE.pdf)
 
 Technical RVI disussions are held at the GENIVI project mailing list:
 [GENIVI](https://lists.genivi.org/mailman/listinfo/genivi-projects)
@@ -151,7 +151,7 @@ with a wide variety of hardware.
 
 ## PYTHON ##
 Python is used to implement all demonstrations, beginning
-with the HVAC demo available in the ```hvac_demo``` subdirectory.
+with the HVAC demo available in the `hvac_demo` subdirectory.
 
 By using Python for the demos, which is better known than erlang,
 examples are given on how to write applications and services
diff --git a/README_ubuntu_14_04.md b/README_ubuntu_14_04.md
new file mode 100644
index 0000000..da36e13
--- /dev/null
+++ b/README_ubuntu_14_04.md
@@ -0,0 +1,20 @@
+# INSTALL INSTRUCTIONS FOR UBUNTU 14.04 PRECISE
+
+1. Install dependent libraries
+sudo apt-get install python-simplejson python-jsonrpclib libwxgtk2.8-0
+
+2. Download esl-erlang 18.2
+wget ttps://packages.erlang-solutions.com/erlang/esl-erlang/FLAVOUR_1_general/esl-erlang_18.2-1~ubuntu~precise_amd64.deb
+
+3. Install esl-erlang
+sudo dpkg -i esl-erlang_18.2-1~ubuntu~precise_amd64.deb
+
+4. Install RVI
+sudo dpkg -i rvi_0.5.0-1ubuntu1_amd64.deb
+
+5. Setup device keys
+Assumes that root key pair is already generated.
+doc/rvi_protocol.md
+
+6. Setup device X.509 Certificates
+
diff --git a/components/dlink_tls/src/dlink_tls_conn.erl b/components/dlink_tls/src/dlink_tls_conn.erl
index 447581d..4629e55 100644
--- a/components/dlink_tls/src/dlink_tls_conn.erl
+++ b/components/dlink_tls/src/dlink_tls_conn.erl
@@ -421,12 +421,13 @@ do_upgrade(Sock, client, CompSpec) ->
     ?debug("TLS Opts = ~p", [Opts]),
     {DoVerify, ssl:connect(Sock, Opts)};
 do_upgrade(Sock, server, CompSpec) ->
-    {DoVerify, Opts} = tls_opts(client, CompSpec),
+    {DoVerify, Opts} = tls_opts(server, CompSpec),
     ?debug("TLS Opts = ~p", [Opts]),
     {DoVerify, ssl:ssl_accept(Sock, Opts)}.
 
 tls_opts(Role, CompSpec) ->
-    TlsOpts = rvi_common:get_value(tls_opts, [], CompSpec),
+    {ok, ServerOpts} = get_module_config(server_opts, [], CompSpec),
+    TlsOpts = rvi_common:get_value(tls_opts, ServerOpts, CompSpec),
     Opt = fun(K) -> opt(K, TlsOpts,
                         fun() ->
                                 ok(setup:get_env(rvi_core, K))
diff --git a/components/dlink_tls/src/dlink_tls_rpc.erl b/components/dlink_tls/src/dlink_tls_rpc.erl
index 014d854..6a90129 100644
--- a/components/dlink_tls/src/dlink_tls_rpc.erl
+++ b/components/dlink_tls/src/dlink_tls_rpc.erl
@@ -222,7 +222,7 @@ connect_remote(IP, Port, CompSpec) ->
 	not_found ->
 	    %% Setup a new outbound connection
 	    {ok, Timeout} = rvi_common:get_module_config(
-			      dlink_tls, ?MODULE, connect_timeout, 10000, CompSpec),
+			      data_link, ?MODULE, connect_timeout, 10000, CompSpec),
 	    ?info("dlink_tls:connect_remote(): Connecting ~p:~p (TO=~p",
 		  [IP, Port, Timeout]),
 	    log("new connection", [], CompSpec),
diff --git a/debian_template/README.Debian b/debian_template/README.Debian
new file mode 100644
index 0000000..f80c683
--- /dev/null
+++ b/debian_template/README.Debian
@@ -0,0 +1,10 @@
+rvi for Debian
+--------------
+
+Will rely on existing Erlang installation to work.
+
+We will copy out the Erlang VM BEAM files to /opt/rvi and the configuration files to /etc/opt/rvi
+
+/opt/rvi/rvi.sh is the main control program.
+
+ -- Magnus Feuer <mfeuer@jaguarlandrover.com>  Fri, 27 Nov 2015 15:34:39 -0800
diff --git a/debian_template/README.source b/debian_template/README.source
new file mode 100644
index 0000000..9e3c927
--- /dev/null
+++ b/debian_template/README.source
@@ -0,0 +1,6 @@
+rvi for Debian
+--------------
+
+
+ -- Magnus Feuer <mfeuer@jaguarlandrover.com>  Fri, 27 Nov 2015 15:34:39 -0800
+
diff --git a/debian_template/changelog b/debian_template/changelog
new file mode 100644
index 0000000..3d774a4
--- /dev/null
+++ b/debian_template/changelog
@@ -0,0 +1,5 @@
+rvi (0.5.0-1) jessie; urgency=low
+
+  * Initial release
+
+ -- Magnus Feuer <mfeuer@jaguarlandrover.com>  Fri, 27 Nov 2015 15:34:39 -0800
diff --git a/debian_template/compat b/debian_template/compat
new file mode 100644
index 0000000..ec63514
--- /dev/null
+++ b/debian_template/compat
@@ -0,0 +1 @@
+9
diff --git a/debian_template/control b/debian_template/control
new file mode 100644
index 0000000..bab7968
--- /dev/null
+++ b/debian_template/control
@@ -0,0 +1,13 @@
+Source: rvi
+Section: net
+Priority: optional
+Maintainer: Magnus Feuer <mfeuer@jaguarlandrover.com>
+Build-Depends: debhelper (>= 9), libbluetooth-dev, esl-erlang (>= 1:18.2)
+Standards-Version: 3.9.6
+Homepage: https://github.com/PDXostc/rvi_core
+
+Package: rvi
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, bluez, esl-erlang (>= 1:18.2), python-jsonrpclib (>= 0.1.3-1), python (>= 2.7.9-1)
+Description: Remote Vehicle Interaction
+ GENIVI Remote Vehicle Interaction Core
diff --git a/debian_template/copyright b/debian_template/copyright
new file mode 100644
index 0000000..89597cf
--- /dev/null
+++ b/debian_template/copyright
@@ -0,0 +1,11 @@
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: rvi
+Source: http://github.com/PDXostc/rvi_core
+
+Files: *
+Copyright:  Copyright 2014,2015,2016 Jaguar Land Rover
+License: MPL-2.0
+ This program is licensed under the terms and conditions of the
+ Mozilla Public License, version 2.0.  The full text of the 
+ Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+
diff --git a/debian_template/docs b/debian_template/docs
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/debian_template/docs
diff --git a/debian_template/rules b/debian_template/rules
new file mode 100755
index 0000000..b6b8c0a
--- /dev/null
+++ b/debian_template/rules
@@ -0,0 +1,21 @@
+#!/usr/bin/make -f
+# -*- makefile --*
+
+# Uncomment this to turn on verbose mode.
+export DH_VERBOSE=1
+
+%:
+	dh $@
+
+override_dh_auto_install:
+	 ./scripts/rvi_install \
+	 	-s ./debian/rvi \
+		-k priv/keys/insecure_device_key.pem \
+		-r priv/certificates/insecure_root_cert.crt \
+		-d priv/certificates/insecure_device_cert.crt \
+		-c priv/credentials/insecure_credential.jwt \
+		-l ./debian/rvi/var/log/rvi ./debian/rvi/usr/lib/rvi_core
+# Copy out rvi_ctl to /usr/bin
+	install -D -m 0755 ./debian/rvi/usr/lib/rvi_core/rvi_ctl ./debian/rvi/usr/bin/rvi_ctl
+# Install default config
+	install -D -m 0644 ./priv/config/rvi_ubuntu.config ./debian/rvi/etc/rvi/rvi.config
diff --git a/debian_template/rvi.init b/debian_template/rvi.init
new file mode 100755
index 0000000..9cd4e59
--- /dev/null
+++ b/debian_template/rvi.init
@@ -0,0 +1,70 @@
+#!/bin/sh
+#
+# Copyright (C) 2014, Jaguar Land Rover
+#
+# This program is licensed under the terms and conditions of the
+# Mozilla Public License, version 2.0.  The full text of the 
+# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+#
+#
+# Init.d script to start and stop an RVI system installed
+# through an RPM.
+#
+### BEGIN INIT INFO
+# Provides:          rvi
+# Required-Start:    $network $syslog $remote_fs
+# Required-Stop:     $network $syslog $remote_fs
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: Start/Stop RVI node at boot time
+# Description:       Manage Remote Vehicle Interaction Node run state.
+### END INIT INFO
+
+export PATH="/bin/:/usr/bin:/sbin:/usr/sbin"
+export HOME=/usr/lib/rvi_core
+. /lib/lsb/init-functions
+
+set -e 
+
+case "$1" in
+  start)
+        log_daemon_msg "Starting Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl -c /etc/rvi/rvi.config start; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+  stop)
+        log_daemon_msg "Stopping Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl stop; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+
+  restart)
+        log_daemon_msg "Restarting Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl restart; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+
+  force-reload)
+        log_daemon_msg "Restarting Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl restart; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+  *)
+	log_action_msg "Usage: /etc/init.d/rvi {start|stop|restart}"
+	exit 1
+esac
+
+exit 0
+
diff --git a/debian_template/rvi.lintian-overrides b/debian_template/rvi.lintian-overrides
new file mode 100644
index 0000000..c307106
--- /dev/null
+++ b/debian_template/rvi.lintian-overrides
@@ -0,0 +1,3 @@
+executable-not-elf-or-script
+missing-dep-for-interpreter
+binary-without-manpage
\ No newline at end of file
diff --git a/debian_template/rvi.postinst b/debian_template/rvi.postinst
new file mode 100644
index 0000000..10c11fe
--- /dev/null
+++ b/debian_template/rvi.postinst
@@ -0,0 +1,45 @@
+#!/bin/sh
+# postinst script for rvi
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#        * <postinst> `configure' <most-recently-configured-version>
+#        * <old-postinst> `abort-upgrade' <new version>
+#        * <conflictor's-postinst> `abort-remove' `in-favour' <package>
+#          <new-version>
+#        * <postinst> `abort-remove'
+#        * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
+#          <failed-install-package> <version> `removing'
+#          <conflicting-package> <version>
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+# source debconf library
+. /usr/share/debconf/confmodule
+
+case "$1" in
+
+  configure)
+    # Set up our config
+    cat /proc/sys/kernel/random/uuid > /etc/rvi/device_id
+    echo "RVI Device ID set to $(cat /etc/rvi/device_id) in /etc/rvi/device_id"
+    #DEBHELPER#
+  ;;
+
+  abort-upgrade|abort-remove|abort-deconfigure)
+    exit 0
+  ;;
+
+  *)
+    echo "postinst called with unknown argument \`$1'" >&2
+    exit 1
+  ;;
+
+esac
+
+db_stop
+
+exit 0
diff --git a/debian_template/rvi.postrm b/debian_template/rvi.postrm
new file mode 100644
index 0000000..a0c5d5b
--- /dev/null
+++ b/debian_template/rvi.postrm
@@ -0,0 +1,40 @@
+#!/bin/sh
+# postrm script for rvi
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#        * <postrm> `remove'
+#        * <postrm> `purge'
+#        * <old-postrm> `upgrade' <new-version>
+#        * <new-postrm> `failed-upgrade' <old-version>
+#        * <new-postrm> `abort-install'
+#        * <new-postrm> `abort-install' <old-version>
+#        * <new-postrm> `abort-upgrade' <old-version>
+#        * <disappearer's-postrm> `disappear' <overwriter>
+#          <overwriter-version>
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+# source debconf library
+. /usr/share/debconf/confmodule
+
+case "$1" in
+
+  remove|purge|upgrde|disappear)
+    rm -f /etc/init.d/rvi
+    #DEBHELPER#
+  ;;
+
+  *)
+    exit 0
+  ;;
+
+
+esac
+
+db_stop
+
+exit 0
diff --git a/debian_template/rvi.service b/debian_template/rvi.service
new file mode 100644
index 0000000..d9ae979
--- /dev/null
+++ b/debian_template/rvi.service
@@ -0,0 +1,18 @@
+# systemd(8) setup for Debian
+
+[Unit]
+Description=Remote Vehicle Interaction Service
+Wants=network-online.target
+
+[Service]
+Environment="HOME=/usr/lib/rvi_core"
+Type=forking
+StandardOutput=journal
+StandardError=journal
+ExecStart=/usr/bin/rvi_ctl -c /etc/rvi/rvi.config start
+ExecStop=/usr/bin/rvi_ctl stop
+GuessMainPID=yes
+RemainAfterExit=yes
+
+[Install]
+WantedBy=graphical.target multi-user.target
diff --git a/debian_template/source/format b/debian_template/source/format
new file mode 100644
index 0000000..163aaf8
--- /dev/null
+++ b/debian_template/source/format
@@ -0,0 +1 @@
+3.0 (quilt)
diff --git a/debian_template/source/lintian-overrides b/debian_template/source/lintian-overrides
new file mode 100644
index 0000000..463abe9
--- /dev/null
+++ b/debian_template/source/lintian-overrides
@@ -0,0 +1 @@
+source-is-missing
diff --git a/deps/exec/rebar.config.script b/deps/exec/rebar.config.script
index 4c7fc65..e24880f 100644
--- a/deps/exec/rebar.config.script
+++ b/deps/exec/rebar.config.script
@@ -1,16 +1,35 @@
-Arch = erlang:system_info(system_architecture),
+%% For cross building using erlang:system_info() does not work as rebar runs
+%% using the build hosts Erlang runtime.
+%% If CXX envrionment variable is defined we are most likely running in a cross environment.
+{CXX,Target,Sysroot} = case os:getenv("CXX") of
+    false -> {"g++",erlang:system_info(system_architecture),""};
+    Compiler -> {Compiler,string:strip(os:cmd(Compiler ++ " -dumpmachine"), right, $\n),string:strip(os:cmd(Compiler ++ " -print-sysroot"), right, $\n)}
+end,
+
+%% Commonly on Linux, compilers report the target triplet as <arch>-<vendor>-linux,
+%% however, Erlang runtime reports and expects it as <arch>-<vendor>-linux-gnu.
+%% Fix by appending "-gnu".
+Mach = case string:str(Target,"linux") of
+    0 -> Target;
+    _ -> case string:words(Target,$-) of
+        4 -> Target;
+        _ -> Target ++ "-gnu"
+        end
+    end,
+
 Vsn  = string:strip(os:cmd("git describe --always --tags --abbrev=0 | sed 's/^v//'"), right, $\n),
+
 %% Check for Linux capability API (Install package: libcap-devel).
 {LinCXX, LinLD} =
-    case file:read_file_info("/usr/include/sys/capability.h") of
+    case file:read_file_info(Sysroot ++ "/usr/include/sys/capability.h") of
     {ok, _} ->
-        io:put_chars("INFO:  Detected support of linux capabilities.\n"),
+        %io:put_chars("INFO:  Detected support of linux capabilities.\n"),
         {" -DHAVE_CAP", " -lcap"};
     _ ->
         {"", ""}
     end,
 
-X64 = case Arch of
+X64 = case Mach of
     "x86_64" ++ _E -> " -m64";
     _              -> ""
     end,
@@ -27,12 +46,12 @@ lists:keymerge(1,
                      {"linux", "CXXFLAGS", "$CXXFLAGS -DHAVE_SETRESUID -DHAVE_PTRACE" ++ LinCXX},
                      {"linux", "LDFLAGS", "$LDFLAGS" ++ LinLD},
 
-                     {"CC",  "g++"},
-                     {"CXX", "g++"},
+                     {"CC",  CXX},
+                     {"CXX", CXX},
                      {"CXXFLAGS", "$CXXFLAGS -O0"}
                     ]},
 
-        {port_specs,[{filename:join(["priv", Arch, "exec-port"]), ["c_src/*.cpp"]}]},
+        {port_specs,[{filename:join(["priv", Mach, "exec-port"]), ["c_src/*.cpp"]}]},
         {edoc_opts, [{overview,     "src/overview.edoc"},
                      {title,        "The exec application"},
                      {includes,     ["include"]},
@@ -41,4 +60,3 @@ lists:keymerge(1,
                      {app_default,  "http://www.erlang.org/doc/man"}]}
     ]),
     lists:keysort(1, CONFIG)).
-
diff --git a/doc/open_issues.md b/doc/open_issues.md
new file mode 100644
index 0000000..4615f7f
--- /dev/null
+++ b/doc/open_issues.md
@@ -0,0 +1,725 @@
+Copyright (C) 2015-16 Jaguar Land Rover
+
+This document is licensed under Creative Commons
+Attribution-ShareAlike 4.0 International.
+
+## OPEN ISSUES
+
+### [1] Public device key exchange as a part of handshake demasks sender
+
+#### Issue Sending the root signed public key during handshake
+identifies the sender to an unknown remote party.
+
+
+#### Solution
+TBD
+
+### [2] Public device key exchange as a part of allows for replay attack
+
+#### Issue
+Sending the root signed public key during handshake allows a malicious
+remote party to replay the signed key, potentially confusing the
+remote part.  Please note that a replay attacker still cannot sign any
+subsequent commands since they do not have the private key
+
+
+#### Solution
+Have the handshake include a random number signed by the private device key
+proves that the sender also posseses the private counterpart.
+
+### [3] Key renewal/revocation scheme needed.
+
+#### Issue
+A generated device or root key has no way of being revoked and/or renewed today.
+
+
+#### Solution
+Have a set of services, similar to the certificate management services, to
+retire old / compromised keys and distribute new ones.
+
+
+### [4] Self provisioning process needs to be validated
+
+#### Issue
+The self provisioing process of a device has too many steps and edge cases.
+
+
+#### Solution
+Document a number of MITM and replay attacks to identify initial set of weaknesses.
+Simplify process.
+
+
+
+### [5] Link-level encryption needs to be implemented
+
+#### Issue
+With the current solution traffic is authenticated and authorized, but not encrypted.
+While an attacker cannot modify or inject traffic, they can listen in to it.
+
+
+#### Solution
+Integrate OpenSSL TLS for session encryption, and possibly also key management.
+
+
+### [6] Ensure that each transaction sent is unique
+
+#### Issue
+Currently the JSON-RPC payload transaction id is just a sequential
+number, which allows for an easy replay attack
+
+
+
+#### Solution
+Make sure that a each transaction is persistent monotonically increased
+for each transaction.
+Have the server ignore transactions from a device that have already been
+executed.
+
+
+### [7] Data Flow Diagrams are needed
+
+#### Issue
+The text-only description is opaque and hard to visualize.
+
+#### Solution
+Create Data Flow Diagrams for all major use cases.
+
+
+
+### [8] STRIDE Application is needed
+
+#### Issue
+There is currently no formal security model, such as STRIDE, applied
+to the document
+
+#### Solution
+Expand and formalize the "Thwarting malicious RVI nodes..." chapters
+to be STRIDE compliant.
+
+
+### [9] STRIDE Application is needed
+
+#### Issue
+Using naked, PEM-encoded root and device keys does not provide expiry time or chains.
+
+#### Solution
+Explore possibility of implementing full-blown certificates for public key management.
+
+
+### [10] Non-intuitive configuration parameter names
+
+#### Issue
+key_pair and provisioning_key are not describing what they are actually
+refering to.
+
+#### Solution
+The following name changes will be done to the configuration parameters:
+
+key_pair - Store single device key pair used to sign outgoing transactions.
+
+Will be renamed device_key_pair.
+
+provisioning_key - Public root key used to validate incoming certificates and device signatures.
+
+Will be renamed public_root_key
+
+### [11] Self provisioning is broken.
+
+#### Issue
+From Rudi's review.
+
+1. Steps 2 through 5: What purpose do steps 2 and 3 serve? You would
+   typically have them if the device and the server would be
+   exchanging session keys that they use to project all the subsequent
+   transactions. Since there are no session keys, for each subsequent
+   transaction the data exchanged has to be signed and validated with
+   the PKI anyway. So, in step 4 the device would have to send the
+   node certificate sent in step 2, since the server cannot rely on
+   that the two transactions are atomic and are actually sent from the
+   same device, even if it says so.
+
+2. I think step 2 must be combined with step 4 and step 3 with step 5,
+   otherwise there is no security. RVI is very much asynchronous and
+   stateless which means with every data exchange the credentials have
+   to be provided.Step 6: The node cert from step 2 that gives the
+   device the right to invoke the service must be provided, because
+   technically the invocation can come from a different device. RVI is
+   stateless, it should be for security reasons anyway.
+
+3. Step 8: The data sent in step 8, the device public key and the
+   token, have to be encrypted with the server's public key, to make
+   sure that only the server can read it and that the message cannot
+   be intercepted by mitm to retrieve the token. Otherwise, the side
+   band token transmission would not make any sense.
+
+4. Steps 9 and 10: They should be combined. The server creates the
+   node certificate and signs the entire certificate, not just the
+   key. The very reason being that the cert includes validity claims
+   that need to be protected from alteration such as valid_after and
+   valid_until time stamps.
+
+5. Step 10: Why would step 10, which creates and signs the node
+   certificate include an authorization to invoke a service on a
+   vehicle, such as the example jlr.com/vin/ABCD/unlock? Those are
+   separate certificates as they have individual validity dates etc.
+
+6. Steps 11 and 12: There is no point in separating the device public
+   key from the node certificate. After the node certificate has been
+   created by the server containing the device's public key in steps 9
+   and 10 (which should be one step, imho), the node certificate is
+   sent to the device. The device receives it and validates the
+   signature and if ok store the cert.
+
+7. All of this should just be for provisioning the device with a node
+   certificate. Providing devices with authorization certificates that
+   allow them to invoke services on vehicles is separate. The
+   provisioning you do once (or maybe a very few times). Providing
+   authorization certificates is a rather frequent action and
+   independent.
+
+
+#### Solution
+Redesign, bottom up.
+
+
+### [12] Python scripts should use cryptocgraphy intead of PyCrypto
+
+#### Issue
+Today, rvi_create_certificate.py and rvi_create_device_key.py use PyCrypto while
+JWT, imported by both scripts, uses cryptography.
+
+
+#### Solution
+rvi_create_certificate.py and rvi_create_device_key.py should be rewritten
+to use cryptography instead of PyCrypto.
+
+
+
+## SETTING UP NODE AUTHENTICATION AND AUTHORIZATION
+
+This document describes the process of setting up root keys, device
+keys, and certificates.
+
+
+## TERMINOLOGY AND COMPONENTS
+
+### Certificate issuer
+A certificate issuer is an entity that signs device keys and
+certificates with a private root key. Devices with the corresponding
+public root key will be able to authenticate signed device keys and
+authorize signed certificates.
+
+### Root key
+A root key, a 4096+ bit RSA key pair, is generated once for an issuer
+of certificates.  The private key is stored in the certificate
+issuer's servers and is not shared.  The public key is manually
+installed on all RVI nodes that are to trust certificates from the
+certificate issuer.
+
+### Device key
+A device key is a per-RVI node 4096+ bit RSA key pair. The private part of
+the device key is stored on a host (server, embedded device, mobile device, etc)
+and is not shared. The public part of the key is used in two ways:
+
+1. **To prove the identity of an RVI node**<br>
+   When two RVI nodes locate each other over a data link (WiFi, 3G,
+   Bluetooth, etc), they exchange an authenticate ("au") packet to
+   prove their identity. This packet has the public part of the device
+   key encoded as a JSON Web Token (JWT - RFC7519) token signed by the
+   private part of the root key.<br> The receiver can use its locally
+   stored public root key to validate that the received public device is
+   signed by the private root key of a trusted certificate issuer.
+
+2. **To prove ownership of certificates.**<br>
+   Embdded in the authenticate packet are one or more certificates
+   proving the sending RVI node's right to register and invoke
+   services. The certificate, signed by the private root key of the
+   issuer, contains the public key of the sending device encoded as
+   JWT structure. This public device key can be used by a
+   receiver to verify the signature of a service invocation requests
+   sent by the remote RVI node.
+
+### Certificate
+
+A certificate is a JSON Web Token, signed by the private root key of
+the certificate issuer, that proves that the RVI node with a given
+public device key has the right to invoke a specific set of services
+and to register another set of services.
+
+The certificate is encoded as a JSON Web Token (JWT) signed
+by the private root key.  The decoded payload has the following JSON
+elements.
+
+Command line parameters to ```rvi_create_certificate.py``` given in
+parenthesis. Items marked with '*' are slated for name changes to
+better reflect JWT practises and RVI semantics.
+
+1. **```iss``` Issuer (```--issuer```)**<br>
+   A domain name identifying the issuer. Currently supported but not
+   used.
+
+2. **```create_timestamp```* - Creation time stamp**<br>
+   Unix time, UTC, when the certificate was created.
+   <br><i>Will be renamed ```iat``` to comply with JWT</i>
+
+3. **```sources```* - Right to register (```--invoke```)**<br>
+   A list of full service names that the certificate grants the right to
+   register, allowing other, credentialed RVI nodes to invoke these
+   services.
+   <br><i>Will be renamed ```register``` to better comply with semantics.</i>
+
+4. **```destinations```* Right to invoke (```--register```)**<br>
+   A list of full service names that the certificate grants the right
+   to invoke on other RVI nodes who have registered them
+   <br><i>Will be renamed ```invoke``` to better comply with semantics.</i>
+
+5. **```keys``` Public device keys (```--device_key```)**<br>
+   Contains one or more (currently only one) public device keys in JSON
+   Web Key (RFC7517) format. The receiver will use this key to validate
+   subsequent service invocations through the signatures submitted with
+   the invocations.
+
+6. **```start```* Start time of validity period (```--start```)**<br>
+   Stored under the ```validity``` JSON element and specifies the Unix
+   time stamp UTC when the certificate becomes valid. The receiving RVI node
+   will check that the current time is not before the ```start``` time stamp
+   of the certificate.
+   <br><i>Will be renamed ```nbf``` to comply with JWT.</i>
+
+7. **```stop```* Stop time of validity period (```--stop```)**<br>
+   Stored under the ```validity``` JSON element and specifies the Unix
+   time stamp UTC when the certificae expires. The receiving RVI node will
+   check that the current time is not after the ```stop``` time stamp
+   of the certificate.
+   <br><i>Will be renamed ```exp``` to comply with JWT.</i>
+
+
+## ASSUMPTIONS ON EXTERNAL COMPONENTS
+
+### Trustworthy time source
+
+In order to validate the active period for certificates (and in the
+future, keys) a trustworthy time source is needed. For devices time
+source is provided by GPS or the mobile network.  For backend servers,
+the source is provided by NTP.
+
+It is up to the deployment project to ensure that these sources cannot be tampered with.
+
+### Secure key store
+
+Device private keys and root private keys are expected to be securerly
+stored on an RVI node through a key vault to prevent unauthorized access.
+
+
+## SETTING UP RVI NETWORK SECURITY - GENERAL FLOW
+
+The general flow of events for setting up security are as follows:
+
+1. **Create root key pair ```rvi_create_root_key.sh```**<br>
+   A single root key is created by the certificate issuer. Two PEM
+   files are created in this process. One PEM file with the
+   private/public key that never leaves the issuer's trusted server,
+   and one public-only PEM file that is installed on every RVI node
+   that is to accept certificates from the issuer.
+
+2. **Create device key pairs ```rvi_create_device_key.py```**<br>
+   Each RVI node need to have its own device key pair. The device key
+   script will create a private/public key PEM file that never leaves
+   the device, a public-only PEM file that is embedded into
+   certificates, and a JWT file with the public device key encoded as
+   a JSON Web Key (JWK - RFC 7159) signed by the private root key
+   generated in step 1.
+
+3. **Create certificates ```rvi_create_certificate.py```**<br>
+   Certificates are generated to allow a specific RVI node (with a
+   given device key) to register (setup) services that it wants other
+   RVI nodes to invoke, and to invoke serivces registered by other RVI
+   nodes The certificate script creates a JWT file, signed by the root
+   key, that encodes the certificate described in the
+   [Certificate](#Certificate) chapter.<br>
+   Certificates are stored on the credentialed RVI node.
+
+
+### Provisioning a root key pair
+
+#### Creating the root key PEM files
+
+The root key, consisting of a private/public RSA4096 key PEM file, and
+a second PEM file with only the public portion of the key, is created
+by the following command:
+
+    rvi_create_root_key.sh -b 4096 -o my_root_key
+
+* **```-b 4096```**<br>
+  Specifies the number of bits in the key.
+
+* **```-o my_root_key```**<br>
+  Specifies the file name prefix of the two created key files.
+
+Once executed, two files will be created:
+
+1. **```my_root_key_priv.pem```**<br>
+   This file contains the private/public key pair that must never leave
+   the credit issuer's trusted environment. It will be used to sign the
+   JWT formatted device key and all certificates created by the
+   certificate issuer.
+
+2. **```my_root_key_pub.pem```**<br>
+   This file contains the public-only key that is to be installed on
+   RVI nodes that will accept device keys and certificates signed by the
+   certificate issuer.
+
+#### Configuring RVI to use a public root key
+Only ```rvi_create_device_key.py``` and ```rvi_create_certificate.py``` use the
+private root key stored in ```my_root_key_priv.pem```, generated above.
+The RVI node itself is never aware of that file.
+
+The RVI node does need the public root key, stored in ```my_root_key_pub.pem```,
+is referenced from the RVI's configuration file stored
+as ```{ rvi_core, { provisioning_key, "..../my_root_key_pub.pem" }}```.
+
+
+
+### Provisioning a device key pair
+
+#### Creating the device key PEM files
+A device key, consisting of a private/public RSA4096 key PEM file, a
+second PEM file with only the public portion of the key, and a third
+JWT is created by the following command:
+
+    rvi_create_device_key.py -p my_root_key_priv.pem -o my_device_key -b 4096
+
+* **```-b 4096```**<br>
+Specifies the number of bits in the device key.<br>
+
+* **```-p my_root_key_priv.pem```**<br>
+Specifies the private root key to sign the device key with when it is
+stored in the JWT file (see below). The root key is created by the
+```rvi_create_root_key.sh``` script.<br>
+
+* **```-o my_device_key```**<br>
+Specifies the file name prefix of the three created device key files.
+
+
+Once executed, three files will be created:
+
+1. **```my_device_key_priv.pem```**<br>
+   This file contains the private/public key pair that must never leave
+   the device's trusted environment. It will be used to sign
+   outgoing service invocation request.
+
+2. **```my_device_key_pub.pem```**<br>
+   This file contains the public-only key that is to be added to
+   certificates issued for the device by a certificate issuer.
+
+3. **```my_device_key_pub_sign.jwt```**<br>
+   This file contains the public-only key, signed by the root key,
+   that is to be provided as authentication when an RVI node identifies
+   itself toward another. The file is stored in JSON Web Token format.
+
+
+#### Configuring RVI to use a device key
+
+The RVI node needs the device private/public key root key, stored in
+```my_device_key_priv.pem```, is referenced from the RVI's configuration
+file in ```{ rvi_core, { key_pair, "..../my_device_key_priv.pem" }}```.
+
+
+### Provisioning a certificate
+
+#### Creating the certificate file
+A certificate is a JWT-formatted JSON structure signed by the root
+private key, is stored on an RVI node to be presented to remote node
+as evidence that the sender has the right to invoke and register the
+specified services.
+
+The certificate is created by the following command
+
+    ./rvi_create_certificate.py --id=my_cert_id \
+                            --device_key=my_device_key_pub.pem \
+                            --start='2015-12-01 00:00:00' \
+                            --stop='2015-12-31 23:59:59' \
+                            --root_key=my_root_key_priv.pem \
+                            --register='jlr.com/vin/abc/unlock jlr.com/vin/abc/lock' \
+                            --invoke='jlr.com/backend/report jlr.com/backend/set_state' \
+                            --jwt_out=my_cert.jwt \
+							--cert_out=my_cert.json \
+                            --issuer=jaguarlandrover.com
+
+The following arguments are provided
+* **```--id=my_cert_id```**<br>
+  System-wide unique ID to be assigned to this certificate.
+
+* **```--device_key=my_device_key_pub.pem```**<br>
+  Specifies that the public device key, generated by ```create_device_key.py```
+  shall be embedded into the generated certificate as the certificate owner.
+
+* **```--root_key=my_root_key_priv.pem```**<br>
+  Specifies that the certificate shall be signed by the private root
+  key generated by ```create_root_key.sh```.
+
+* **```--invoke='jlr.com/backend/report jlr.com/backend/set_state'```**<br>
+  Gives the device with the certificate-embedded public key the right to invoke
+  the services ```jlr.com/backend/report``` and ```jlr.com/backend/set_state```.
+
+* **```--register='jlr.com/vin/abc/unlock jlr.com/vin/abc/lock'```**<br>
+  Gives the device with the certificate-embedded public key the right to register
+  the services ```jlr.com/backend/report``` and ```jlr.com/backend/set_state```.
+
+* **```--start='2015-12-01 00:00:00'```**<br>
+  Specifies that the certificate shall become valid Dec 1, 2015 at
+  midnight.
+
+* **```--stop='2015-12-31 23:59:59'```**<br>
+  Specifies that the certificate shall expire valid Dec 31, 2015 at
+  11:59:59 PM.
+
+* **```--jwt_out=my_cert.jwt```**<br>
+  Specifies the name of the JWT file that is to be written with the
+  certificate signed by the root key in ```my_root_key_priv.pem```.
+
+* **```--cert_out=my_cert.json```**<br>
+  Specifies a file to write a JSON-formatted copy of the certificate into.
+  This file is for human inspection only and is not used by RVI or any other
+  scripts.
+
+* **```--issuer=jaguarlandrover.com```**<br>
+  Specifies that the certificate issuer is ```jaguarlandrover.com```.
+  This value is currently not used.
+
+
+Once executed, one mandatory and one optional file will be created:
+
+1. **```my_cert.jwt```**<br>
+   This file contains the generated certificate, signed by the
+   private root key specified by ```--root_key=```. The content
+   of this file will be provided by an RVI node to prove its righ
+   to register and invoke services toward remote RVI nodes
+
+
+2. **```my_cert.json```**<br>
+   Only created if ```--cert_out=``` has been give. Contains a human
+   readable JSON form of the generated root key.
+
+
+#### Configuring RVI to use a certificate
+The RVI node needs the certificates to prove its right to register and invoke
+services toward remote nodes. The generated
+certificate file, ```my_cert.jwt```, is placed in a directory with other
+certificates owned by the device.
+
+The certificate directory itself is referenced from the RVI's
+configuration file in ```{ rvi_core, { cert_dir, "...." }}```.
+
+
+
+
+## DEVICE SELF PROVISIONING THROUGH ONE-TIME TOKENS
+
+This chapter describes a yet-to-be-implemented procedure
+for provisioning new devices that are created outside
+the control of the provisioning server.
+
+### Initial provisioning at app install
+An device-specific key pair is generated by device and stored locally.
+
+The app has one pre-provisioned certificate, signed by the
+root server, allowing it to invoke ```jlr.com/provisioning/init_setup```
+and ```jlr.com/provisioning/request_provisioning```. The certificate also
+provides the right to register ```jlr.com/mobile/*/dm/cert_provision```
+and ```jlr.com/mobile/*/dm/signed_pub_key_provision```
+The certificate keys section, normally holding public device
+keys, is empty.
+
+The device has the public root key pre-provisioned.
+
+The device has the BT/IP/SMS address of its provisioning server to
+setup an initial contact.
+
+### Device self provisioning process
+**BROKEN WILL BE REDESIGNED**
+
+1. Device connects to provisioning server<br>
+   The app is started for the first time and connects to the
+   provisioning server.
+
+2. Device sends authenticate to server<br>
+   The command contains no key, only a single pre-provisioned node certificate giving
+   the device the right to invoke and register the functions listed in
+   above.<br>
+
+3. Server sends authenticate to device<br>
+   The server's public device key, signed by the root private key, is
+   sent together with no node certificates, thus giving the server no
+   rights to register or invoke services with the device.
+
+4. Device sends a service announce to server<br>
+   After validating server authenticate package, the device
+   sends a service announce to the server.
+   The command contains the services ```jlr.com/mobile/1234/dm/cert_provision```
+   and  ```jlr.com/mobile/1234/dm/signed_pub_key_provision```,
+   which can be invoked by the provisioning service to install a new
+   certificate and signed public device key on the device.
+
+5. Server sends a service announce to device<br>
+   The announcement contains the services ```jlr.com/provisioning/init_setup```
+   and```jlr.com/provisioning/request_provisioning``` .
+
+6. Device invokes ```jlr.com/provisioning/init_setup``` on server<br>
+   The sole argument is the device ID, e.g. 1234.  The command is
+   validated by the server through the pre-provisioned cert. Since
+   the cert contains no device public key, any device can invoke it.
+
+7. Sideband token transmission from provisioning service to device<br>
+   The provisioning server transmits a 128 bit random token to the device
+   using a sideband channel such as SMS or similar.
+
+8. Device invokes ```jlr.com/provisioning/request_provisioning``` on server<br>
+   The device provides its public key, and the token received in step 7 as
+   arguments to the call.
+
+9. Provisioning service signs device public key<br>
+   The provisioning service checks that the token has not expired.<br>
+   The provisioning service checks that the token has not already been used.<br>
+   The public key provided in step 8 is signed by the root private key.
+
+10. Provisioning service creates node certificates<br>
+    The created cert gives the holder the right to invoke ```jlr.com/vin/ABCD/unlock```.<br>
+    The certificate also gives the holder the right to register ```jlr.com/mobile/1234/status.```<br>
+    The certificate includes the device public key provided in step 8.
+    The certificate is signed by the private root key.<br>
+
+11. Provisioning service invokes ```jlr.com/mobile/1234/dm/signed_pub_key_provision```<br>
+    The provisioning service invokes key provisioning service on
+    the device, announced by the device to the service in step 4, to
+    install the signed public device key on the device.<br>
+	The key, signed in step 9, is provided as a single argument.
+	The device matches the key with its existing key.<br>
+	The device validates the signature using the pre-provisioned public root key.<br>
+	The device stores the signed public key to be used in future authentication messages.
+
+12. Provisioning service invokes ```jlr.com/mobile/1234/dm/cert_provision```<br>
+    The provisioning service invokes certificate provisioning service on
+    the device, announced by the device to the service in step 4, to
+    install the certificate created in step 10.<br>
+	The device matches the public key of the certificate against its own public key<br>
+	The device validates the signature using the pre-provisioned public root key.<br>
+	The device stores the signed certificate to be used in future authentication messages.
+
+
+## DEVICE - VEHICLE SESSION USE CASE
+
+In this use case, a mobile device, with ID 1234, connects to a
+vehicle, with VIN ABCD, to unlock it.
+
+The vehicle has a service, registered as ```jlr.com/vin/ABCD/request_unlock```, which
+unlocks the door.
+
+The mobile device has a service, registered as ```jlr.com/mobile/1234/confirm_unlock```,
+which updates the UI with the current state of the door locks.
+
+The device will invoke ```jlr.com/vin/ABCD/request_unlock``` to unlock the
+doors of the vehicle, while the vehicle will confirm its new unlocked
+state through a invocation to ```jlr.com/mobile/1234/confirm_unlock```
+
+1. Device 1234 connects to vehicle ABCD<br>
+   Connection is done over bluetooth, with no Internet connection.
+
+2. Device sends authenticate to vehicle<br>
+   The command contains the root-signed public device key from step 11 in the previous chapter.<br>
+   The command contains the root-signed certificate from step 12 in the previous chapter.<br>
+   The vehicle verifies the public device key signature using the pre-provisioned public root key.<br>
+   The vehicle verifies the certificate signature using the pre-provisioned public root key.<br>
+   The vehicle marks the device as being allowed to invoke ```jlr.com/vin/ABCD/request_unlock```<br>
+   The vehicle marks the device as being allowed to register ```jlr.com/mobile/1234/confirm_unlock```<br>
+
+3. Vehicle sends authenticate to device<br>
+   The command contains a root-signed public device key for the vehicle
+   The command contains a root-signed certificate, allowing the
+   vehicle to invoke ```jlr.com/vin/*/confirm_unlock```, and
+   register ```jlr.com/vin/ABCD/request_unlock```.<br>
+   The device verifies the public device key signature using the pre-provisioned public root key.<br>
+   The device verifies the certificate signature using the pre-provisioned public root key.<br>
+   The device marks the vehicle as being allowed to invoke ```jlr.com/mobile/1234/confirm_unlock```<br>
+   The device marks the vehicle as being allowed to register ```jlr.com/vin/ABCD/request_unlock```<br>
+
+
+4. Device sends service announce to vehicle<br>
+   The command contains ```jlr.com/mobile/1234/confirm_unlock```.<br>
+   Vehicle validates that the vehicle has the right to register this
+   service against the certificate received in step 2.
+
+5. Vehicle sends service announce to device<br>
+   The command contains the service ```jlr.com/vin/ABCD/request_unlock```.<br>
+   Device validates the registration against right to register services
+   listed in certificate received in step 3.<br>
+
+
+6. Device invokes ```jlr.com/vin/ABCD/request_unlock``` on vehicle<br>
+   The command, signed by the device private key, tells the
+   vehicle to unlock its doors.<br>
+   The certificate transmitted in step 2 proves that the device
+   has the right to invoke the command on the vehicle.<br>
+   The vehicle validates the signature using the public key in
+   the certificate transmitted in step 2.<br>
+   The vehicle unlocks the doors.
+
+7. Vehicle invokes ```jlr.com/mobile/1234/confirm_status``` on device<br>
+   The command, signed by the vehicle private key, acknowledges
+   to the device that the doors have been unlocked.<br>
+   The certificate transmitted in step 3 proves that the vehicle
+   has the right to invoke the command on the device.<br>
+   The device validates the signature using the public key in
+   the certificate transmitted in step 3.<br>
+   The device updates its UI with an unlocked icon.
+
+
+
+### Thwarting malicious RVI nodes - Illegal service invocation
+
+1. [standard session setup]<br>
+
+2. Device sends authenticate command to server<br>
+   The command contains the device key together with a certificate showing
+   that the device has the right to register register ```jlr.com/mobile/1234/receive_bitcoin```.
+
+3. [server validates and responds with its own authenticate]<br>
+
+4. Device sends false service announce to server<br>
+   The commands contains the service ```jlr.com/mobile/9999/receive_bitcoin```.
+
+5. Server rejects the service announce<br>
+   Since the announced service does not match the right-to-invoke section in the
+   certificate received in step 2, the announcement is rejected and no
+   invocations to ```jlr.com/mobile/9999/receive_bitcoin``` will be routed to
+   device.
+
+### Thwarting malicious RVI nodes - Stolen certificates
+1. [standard session setup]<br>
+
+2. Device sends authenticate command to server<br>
+   The command contains the root-signed public device key together
+   with a *stolen* certificate, also root signed, showing that the device has the right
+   to register register ```jlr.com/mobile/1234/receive_bitcoin```.<br>
+
+3. Server fails to validate certificate<br>
+   Server tries to match public key in stolen, root signed certificate against the
+   root signed public key in the authenticate, and fails.<br>
+   Server disconnects.
+
+### Thwarting self-provisioning process - Replay TBD.
+
+The provisioning server, having matched the side band address (MSISDN) against an internal database of devices and their access rights, will create a specific certificate only for that device.
+
+Given that the side band network has not been compromised, I can't see how a MITM / replay attack can give a remote remote attacker the ability to gain access of the root-signed public device key and/or use a certificate.
+
+The token is sent as side band data to the correct device.
+
+The device presents token and public key when it invokes the server's request_provisioning service, proving that it has received the token.
+
+The server signs the public key, proven to be received from the correct device, and invoke the device's key_provision service to store it. The request is signed by the private root key, proving to the server is not spoofed.
+
+### Thwarting self-provisioning process - Cloned phone
+
+## KEY LIFECYCLE MANAGEMENT
+TBD
diff --git a/doc/pdf/BUILD.pdf b/doc/pdf/BUILD.pdf
new file mode 100644
index 0000000..dc14200
--- /dev/null
+++ b/doc/pdf/BUILD.pdf
diff --git a/doc/pdf/CONFIGURE.pdf b/doc/pdf/CONFIGURE.pdf
new file mode 100644
index 0000000..013da57
--- /dev/null
+++ b/doc/pdf/CONFIGURE.pdf
diff --git a/doc/pdf/rvi_fragmentation.pdf b/doc/pdf/rvi_fragmentation.pdf
new file mode 100644
index 0000000..754566d
--- /dev/null
+++ b/doc/pdf/rvi_fragmentation.pdf
diff --git a/doc/pdf/rvi_protocol.pdf b/doc/pdf/rvi_protocol.pdf
new file mode 100644
index 0000000..95f72e1
--- /dev/null
+++ b/doc/pdf/rvi_protocol.pdf
diff --git a/doc/pdf/rvi_services.pdf b/doc/pdf/rvi_services.pdf
new file mode 100644
index 0000000..b42829f
--- /dev/null
+++ b/doc/pdf/rvi_services.pdf
diff --git a/doc/rvi_fragmentation.md b/doc/rvi_fragmentation.md
index 78362c9..0992005 100644
--- a/doc/rvi_fragmentation.md
+++ b/doc/rvi_fragmentation.md
@@ -1,13 +1,21 @@
+<style type="text/css" media="print">
+  div.pagebreak
+  {
+    page-break-before: always;
+  }
+</style>
 # The RVI Core Fragmentation Protocol
 
 ## Abstract
 
-The Remote Vehicle Interaction (RVI) system is a framework for secure interaction between
-vehicles and other devices and/or cloud services. RVI is designed to be agnostic in regard
-to connectivity options and intermittent connectivity. One consequence of this is that
-large messages may have to be partially transmitted via one type of connection, and completed
-on another. The fragmentation protocol described below allows for varying Message Transfer
-Unit (MTU) and lets the remote client request fragments as needed.
+The Remote Vehicle Interaction (RVI) system is a framework for secure
+interaction between vehicles and other devices and/or cloud services.
+RVI is designed to be agnostic in regard to connectivity options and
+intermittent connectivity. One consequence of this is that large messages
+may have to be partially transmitted via one type of connection, and completed
+on another. The fragmentation protocol described below allows for varying
+Message Transfer Unit (MTU) and lets the remote client request fragments
+as needed.
 
 ## Status of This Memo
 
@@ -41,6 +49,8 @@ Term      | Meaning
 `Server`  | Receiving side of the interaction
 `MTU`     | Message Transfer Unit
 
+<div class="pagebreak"></div>
+
 ## System Overview
 
 The fragmentation support is intended to operate immediately on top of the transport
diff --git a/doc/rvi_protocol.md b/doc/rvi_protocol.md
index 62765a3..ce9c445 100644
--- a/doc/rvi_protocol.md
+++ b/doc/rvi_protocol.md
@@ -1,3 +1,9 @@
+<style type="text/css" media="print">
+  div.pagebreak
+  {
+    page-break-before: always;
+  }
+</style>
 Copyright (C) 2015-16 Jaguar Land Rover
 
 This document is licensed under Creative Commons
@@ -49,6 +55,7 @@ Public Key Infrastructure and certificate distribution.
 6. **RVI Node Discovery**<br>
 Allowing two unconnected RVI nodes to discover each other so that they can initiate connection.
 
+<div class="pagebreak"></div>
 
 # OVERVIEW
 The RVI core protocol is the default protocol used between two RVI
@@ -64,7 +71,6 @@ encoder/decoder to transmit JSON structures. All JSON structures described in
 this protocol are encoded as MessagePack prior to transmission to the remote
 peer.
 
-
 ## Certificates and credentials
 Three types of certificates and credentials are used by the RVI Core
 protocol in conjunciton with TLS. See [6] for details on X.509.
@@ -84,6 +90,7 @@ services that the device has right to register.
 Embeds the device X.509 certificate as a PEM-encoded string.
 Signed by root cert.
 
+<div class="pagebreak"></div>
 
 ## Integration between TLS and RVI Core RVI
 Client and server X.509 certificates are exchanged when the original
@@ -111,6 +118,8 @@ client-server terminology only denotes who initiates the connection
 
 <img src="images/rvi_protocol_flow.png" alt="RVI Core protocol Sequence Diagram" style="width:800">
 
+<div class="pagebreak"></div>
+
 ## Authorize command
 The ```authorize``` command contains a list of RVI credentials, each specifying
 a set of services that the sender has the right to invoke on the receiving node,
@@ -118,7 +127,6 @@ and a set of services that the sender has the right to register.
 
 Please see the "RVI Credentials" chapter for detailss on RVI credentials.
 
-
 ## Service Announce command
 The ```service_authorize``` command contains a list of services
 available on the sender that match services listed in RVI credentials
@@ -171,6 +179,8 @@ Node1 Address         | Node2 Address       | Connecting side to be terminated
 The connection is terminated regardless of its current protocol
 session state.
 
+<div class="pagebreak"></div>
+
 ## Chunking of large messages
 
 RVI Core is able to split large messages into fragments and deliver them
@@ -211,6 +221,8 @@ fragment (with a starting offset of 1), and then wait for the receiving side
 to request more fragments using "frg-get" messages. When the sending side
 receives a "frg-end" message, it will forget about the message.
 
+<div class="pagebreak"></div>
+
 ### Encoding
 
 By default, the fragmentation logic will use the same encoding as the
@@ -250,7 +262,7 @@ The self signed root certificate used in the examples throughout this
 document was generated using the following commands:
 
 ```Shell
-# Create root key and cert signing request
+# Create root key pair
 openssl genrsa -out insecure_root_key.pem 1024
 
 # Create a self-signed root CA certificate, signed by the root key created above
@@ -278,7 +290,9 @@ ZA2UwSzj67PBc5umDIAlhVRMX0zH/gLj54rfIkH5zLk=
 -----END RSA PRIVATE KEY-----
 ```
 
-The root key above is checked in as ```priv/sample_keys/insecure_root_key.pem```.
+The root key above is checked in as ```priv/keys/insecure_root_key.pem```.
+
+<div class="pagebreak"></div>
 
 The content of the sample ```insecure_root_cert.crt``` file is:
 
@@ -300,7 +314,7 @@ mVrUm0lY/n2ilJQ1hzBZ9lFLq0wfjw==
 -----END CERTIFICATE-----
 ```
 
-The root certificate above is checked in as ```priv/sample_certificates/insecure_root_key.pem```.
+The root certificate above is checked in as ```priv/certificates/insecure_root_cert.crt```.
 
 
 **DO NOT USE THE KEYS AND CERTIFICATES ABOVE IN PRODUCTION!<br>
@@ -315,10 +329,10 @@ was generated with the following command:
 # Create the device key. In production, increase the bit size to 4096+
 openssl genrsa -out insecure_device_key.pem 1024
 
-# Create a certificate signing requestsigning request
+# Create a certificate signing request
 openssl req -new -key insecure_device_key.pem -out insecure_device_cert.csr
 
-# Sign the signing request and creaqte the root_cert.crt file
+# Sign the signing request and create the insecure_device_cert.crt file
 openssl x509 -req -days 365 -in insecure_device_cert.csr \
              -CA insecure_root_cert.crt -CAkey insecure_root_key.pem \
              -set_serial 01 -out insecure_device_cert.crt
@@ -349,6 +363,7 @@ G9jkH/AfO35GP3RiWQJBAJLWBlKpHf8TxT65jAwxBhd9ZOkC2w0WidbSYjX9wkkD
 -----END RSA PRIVATE KEY-----
 ```
 
+<div class="pagebreak"></div>
 
 The content of the sample ```insecure_device_cert.crt``` file is:
 
@@ -368,7 +383,7 @@ PwSMHih1bsTRpyY5Z3CUDcDJkYtVbYs=
 -----END CERTIFICATE-----
 ```
 
-These files are checked into ```priv/sample_certifcates``` and ```priv/sample_keys```.
+These files are checked into ```priv/certifcates``` and ```priv/keys```.
 
 **DO NOT USE THE KEYS AND CERTIFICATES ABOVE IN PRODUCTION!<br>
 ANY PRODUCTION KEYS SHOULD BE GENERATED BY THE ORGANIZATION AND BE 4096 BITS LONG.**
@@ -427,6 +442,7 @@ An RVI credential has the following format in its native JSON state:
 }
 ```
 
+<div class="pagebreak"></div>
 
 The members are as follows:
 
@@ -472,729 +488,4 @@ Parameter      | Required | Description
 --stop         | No       | The Unix timestamps when the credential becomes inactive.
 
 The generated ```insecure_credential.json```
-and ```insecure_credential.jwt``` are checked into ```priv/sample_credentials```.
-
-
-# DOCUMENTATION ENDS HERE. EVERYTHING BELOW IS RESIDUAL
-
-
-## OPEN ISSUES
-
-### [1] Public device key exchange as a part of handshake demasks sender
-
-#### Issue Sending the root signed public key during handshake
-identifies the sender to an unknown remote party.
-
-
-#### Solution
-TBD
-
-### [2] Public device key exchange as a part of allows for replay attack
-
-#### Issue
-Sending the root signed public key during handshake allows a malicious
-remote party to replay the signed key, potentially confusing the
-remote part.  Please note that a replay attacker still cannot sign any
-subsequent commands since they do not have the private key
-
-
-#### Solution
-Have the handshake include a random number signed by the private device key
-proves that the sender also posseses the private counterpart.
-
-### [3] Key renewal/revocation scheme needed.
-
-#### Issue
-A generated device or root key has no way of being revoked and/or renewed today.
-
-
-#### Solution
-Have a set of services, similar to the certificate management services, to
-retire old / compromised keys and distribute new ones.
-
-
-### [4] Self provisioning process needs to be validated
-
-#### Issue
-The self provisioing process of a device has too many steps and edge cases.
-
-
-#### Solution
-Document a number of MITM and replay attacks to identify initial set of weaknesses.
-Simplify process.
-
-
-
-### [5] Link-level encryption needs to be implemented
-
-#### Issue
-With the current solution traffic is authenticated and authorized, but not encrypted.
-While an attacker cannot modify or inject traffic, they can listen in to it.
-
-
-#### Solution
-Integrate OpenSSL TLS for session encryption, and possibly also key management.
-
-
-### [6] Ensure that each transaction sent is unique
-
-#### Issue
-Currently the JSON-RPC payload transaction id is just a sequential
-number, which allows for an easy replay attack
-
-
-
-#### Solution
-Make sure that a each transaction is persistent monotonically increased
-for each transaction.
-Have the server ignore transactions from a device that have already been
-executed.
-
-
-### [7] Data Flow Diagrams are needed
-
-#### Issue
-The text-only description is opaque and hard to visualize.
-
-#### Solution
-Create Data Flow Diagrams for all major use cases.
-
-
-
-### [8] STRIDE Application is needed
-
-#### Issue
-There is currently no formal security model, such as STRIDE, applied
-to the document
-
-#### Solution
-Expand and formalize the "Thwarting malicious RVI nodes..." chapters
-to be STRIDE compliant.
-
-
-### [9] STRIDE Application is needed
-
-#### Issue
-Using naked, PEM-encoded root and device keys does not provide expiry time or chains.
-
-#### Solution
-Explore possibility of implementing full-blown certificates for public key management.
-
-
-### [10] Non-intuitive configuration parameter names
-
-#### Issue
-key_pair and provisioning_key are not describing what they are actually
-refering to.
-
-#### Solution
-The following name changes will be done to the configuration parameters:
-
-key_pair - Store single device key pair used to sign outgoing transactions.
-
-Will be renamed device_key_pair.
-
-provisioning_key - Public root key used to validate incoming certificates and device signatures.
-
-Will be renamed public_root_key
-
-### [11] Self provisioning is broken.
-
-#### Issue
-From Rudi's review.
-
-1. Steps 2 through 5: What purpose do steps 2 and 3 serve? You would
-   typically have them if the device and the server would be
-   exchanging session keys that they use to project all the subsequent
-   transactions. Since there are no session keys, for each subsequent
-   transaction the data exchanged has to be signed and validated with
-   the PKI anyway. So, in step 4 the device would have to send the
-   node certificate sent in step 2, since the server cannot rely on
-   that the two transactions are atomic and are actually sent from the
-   same device, even if it says so.
-
-2. I think step 2 must be combined with step 4 and step 3 with step 5,
-   otherwise there is no security. RVI is very much asynchronous and
-   stateless which means with every data exchange the credentials have
-   to be provided.Step 6: The node cert from step 2 that gives the
-   device the right to invoke the service must be provided, because
-   technically the invocation can come from a different device. RVI is
-   stateless, it should be for security reasons anyway.
-
-3. Step 8: The data sent in step 8, the device public key and the
-   token, have to be encrypted with the server's public key, to make
-   sure that only the server can read it and that the message cannot
-   be intercepted by mitm to retrieve the token. Otherwise, the side
-   band token transmission would not make any sense.
-
-4. Steps 9 and 10: They should be combined. The server creates the
-   node certificate and signs the entire certificate, not just the
-   key. The very reason being that the cert includes validity claims
-   that need to be protected from alteration such as valid_after and
-   valid_until time stamps.
-
-5. Step 10: Why would step 10, which creates and signs the node
-   certificate include an authorization to invoke a service on a
-   vehicle, such as the example jlr.com/vin/ABCD/unlock? Those are
-   separate certificates as they have individual validity dates etc.
-
-6. Steps 11 and 12: There is no point in separating the device public
-   key from the node certificate. After the node certificate has been
-   created by the server containing the device's public key in steps 9
-   and 10 (which should be one step, imho), the node certificate is
-   sent to the device. The device receives it and validates the
-   signature and if ok store the cert.
-
-7. All of this should just be for provisioning the device with a node
-   certificate. Providing devices with authorization certificates that
-   allow them to invoke services on vehicles is separate. The
-   provisioning you do once (or maybe a very few times). Providing
-   authorization certificates is a rather frequent action and
-   independent.
-
-
-#### Solution
-Redesign, bottom up.
-
-
-### [12] Python scripts should use cryptocgraphy intead of PyCrypto
-
-#### Issue
-Today, rvi_create_certificate.py and rvi_create_device_key.py use PyCrypto while
-JWT, imported by both scripts, uses cryptography.
-
-
-#### Solution
-rvi_create_certificate.py and rvi_create_device_key.py should be rewritten
-to use cryptography instead of PyCrypto.
-
-
-
-## SETTING UP NODE AUTHENTICATION AND AUTHORIZATION
-
-This document describes the process of setting up root keys, device
-keys, and certificates.
-
-
-## TERMINOLOGY AND COMPONENTS
-
-### Certificate issuer
-A certificate issuer is an entity that signs device keys and
-certificates with a private root key. Devices with the corresponding
-public root key will be able to authenticate signed device keys and
-authorize signed certificates.
-
-### Root key
-A root key, a 4096+ bit RSA key pair, is generated once for an issuer
-of certificates.  The private key is stored in the certificate
-issuer's servers and is not shared.  The public key is manually
-installed on all RVI nodes that are to trust certificates from the
-certificate issuer.
-
-### Device key
-A device key is a per-RVI node 4096+ bit RSA key pair. The private part of
-the device key is stored on a host (server, embedded device, mobile device, etc)
-and is not shared. The public part of the key is used in two ways:
-
-1. **To prove the identity of an RVI node**<br>
-   When two RVI nodes locate each other over a data link (WiFi, 3G,
-   Bluetooth, etc), they exchange an authenticate ("au") packet to
-   prove their identity. This packet has the public part of the device
-   key encoded as a JSON Web Token (JWT - RFC7519) token signed by the
-   private part of the root key.<br> The receiver can use its locally
-   stored public root key to validate that the received public device is
-   signed by the private root key of a trusted certificate issuer.
-
-2. **To prove ownership of certificates.**<br>
-   Embdded in the authenticate packet are one or more certificates
-   proving the sending RVI node's right to register and invoke
-   services. The certificate, signed by the private root key of the
-   issuer, contains the public key of the sending device encoded as
-   JWT structure. This public device key can be used by a
-   receiver to verify the signature of a service invocation requests
-   sent by the remote RVI node.
-
-### Certificate
-
-A certificate is a JSON Web Token, signed by the private root key of
-the certificate issuer, that proves that the RVI node with a given
-public device key has the right to invoke a specific set of services
-and to register another set of services.
-
-The certificate is encoded as a JSON Web Token (JWT) signed
-by the private root key.  The decoded payload has the following JSON
-elements.
-
-Command line parameters to ```rvi_create_certificate.py``` given in
-parenthesis. Items marked with '*' are slated for name changes to
-better reflect JWT practises and RVI semantics.
-
-1. **```iss``` Issuer (```--issuer```)**<br>
-   A domain name identifying the issuer. Currently supported but not
-   used.
-
-2. **```create_timestamp```* - Creation time stamp**<br>
-   Unix time, UTC, when the certificate was created.
-   <br><i>Will be renamed ```iat``` to comply with JWT</i>
-
-3. **```sources```* - Right to register (```--invoke```)**<br>
-   A list of full service names that the certificate grants the right to
-   register, allowing other, credentialed RVI nodes to invoke these
-   services.
-   <br><i>Will be renamed ```register``` to better comply with semantics.</i>
-
-4. **```destinations```* Right to invoke (```--register```)**<br>
-   A list of full service names that the certificate grants the right
-   to invoke on other RVI nodes who have registered them
-   <br><i>Will be renamed ```invoke``` to better comply with semantics.</i>
-
-5. **```keys``` Public device keys (```--device_key```)**<br>
-   Contains one or more (currently only one) public device keys in JSON
-   Web Key (RFC7517) format. The receiver will use this key to validate
-   subsequent service invocations through the signatures submitted with
-   the invocations.
-
-6. **```start```* Start time of validity period (```--start```)**<br>
-   Stored under the ```validity``` JSON element and specifies the Unix
-   time stamp UTC when the certificate becomes valid. The receiving RVI node
-   will check that the current time is not before the ```start``` time stamp
-   of the certificate.
-   <br><i>Will be renamed ```nbf``` to comply with JWT.</i>
-
-7. **```stop```* Stop time of validity period (```--stop```)**<br>
-   Stored under the ```validity``` JSON element and specifies the Unix
-   time stamp UTC when the certificae expires. The receiving RVI node will
-   check that the current time is not after the ```stop``` time stamp
-   of the certificate.
-   <br><i>Will be renamed ```exp``` to comply with JWT.</i>
-
-
-## ASSUMPTIONS ON EXTERNAL COMPONENTS
-
-### Trustworthy time source
-
-In order to validate the active period for certificates (and in the
-future, keys) a trustworthy time source is needed. For devices time
-source is provided by GPS or the mobile network.  For backend servers,
-the source is provided by NTP.
-
-It is up to the deployment project to ensure that these sources cannot be tampered with.
-
-### Secure key store
-
-Device private keys and root private keys are expected to be securerly
-stored on an RVI node through a key vault to prevent unauthorized access.
-
-
-## SETTING UP RVI NETWORK SECURITY - GENERAL FLOW
-
-The general flow of events for setting up security are as follows:
-
-1. **Create root key pair ```rvi_create_root_key.sh```**<br>
-   A single root key is created by the certificate issuer. Two PEM
-   files are created in this process. One PEM file with the
-   private/public key that never leaves the issuer's trusted server,
-   and one public-only PEM file that is installed on every RVI node
-   that is to accept certificates from the issuer.
-
-2. **Create device key pairs ```rvi_create_device_key.py```**<br>
-   Each RVI node need to have its own device key pair. The device key
-   script will create a private/public key PEM file that never leaves
-   the device, a public-only PEM file that is embedded into
-   certificates, and a JWT file with the public device key encoded as
-   a JSON Web Key (JWK - RFC 7159) signed by the private root key
-   generated in step 1.
-
-3. **Create certificates ```rvi_create_certificate.py```**<br>
-   Certificates are generated to allow a specific RVI node (with a
-   given device key) to register (setup) services that it wants other
-   RVI nodes to invoke, and to invoke serivces registered by other RVI
-   nodes The certificate script creates a JWT file, signed by the root
-   key, that encodes the certificate described in the
-   [Certificate](#Certificate) chapter.<br>
-   Certificates are stored on the credentialed RVI node.
-
-
-### Provisioning a root key pair
-
-#### Creating the root key PEM files
-
-The root key, consisting of a private/public RSA4096 key PEM file, and
-a second PEM file with only the public portion of the key, is created
-by the following command:
-
-    rvi_create_root_key.sh -b 4096 -o my_root_key
-
-* **```-b 4096```**<br>
-  Specifies the number of bits in the key.
-
-* **```-o my_root_key```**<br>
-  Specifies the file name prefix of the two created key files.
-
-Once executed, two files will be created:
-
-1. **```my_root_key_priv.pem```**<br>
-   This file contains the private/public key pair that must never leave
-   the credit issuer's trusted environment. It will be used to sign the
-   JWT formatted device key and all certificates created by the
-   certificate issuer.
-
-2. **```my_root_key_pub.pem```**<br>
-   This file contains the public-only key that is to be installed on
-   RVI nodes that will accept device keys and certificates signed by the
-   certificate issuer.
-
-#### Configuring RVI to use a public root key
-Only ```rvi_create_device_key.py``` and ```rvi_create_certificate.py``` use the
-private root key stored in ```my_root_key_priv.pem```, generated above.
-The RVI node itself is never aware of that file.
-
-The RVI node does need the public root key, stored in ```my_root_key_pub.pem```,
-is referenced from the RVI's configuration file stored
-as ```{ rvi_core, { provisioning_key, "..../my_root_key_pub.pem" }}```.
-
-
-
-### Provisioning a device key pair
-
-#### Creating the device key PEM files
-A device key, consisting of a private/public RSA4096 key PEM file, a
-second PEM file with only the public portion of the key, and a third
-JWT is created by the following command:
-
-    rvi_create_device_key.py -p my_root_key_priv.pem -o my_device_key -b 4096
-
-* **```-b 4096```**<br>
-Specifies the number of bits in the device key.<br>
-
-* **```-p my_root_key_priv.pem```**<br>
-Specifies the private root key to sign the device key with when it is
-stored in the JWT file (see below). The root key is created by the
-```rvi_create_root_key.sh``` script.<br>
-
-* **```-o my_device_key```**<br>
-Specifies the file name prefix of the three created device key files.
-
-
-Once executed, three files will be created:
-
-1. **```my_device_key_priv.pem```**<br>
-   This file contains the private/public key pair that must never leave
-   the device's trusted environment. It will be used to sign
-   outgoing service invocation request.
-
-2. **```my_device_key_pub.pem```**<br>
-   This file contains the public-only key that is to be added to
-   certificates issued for the device by a certificate issuer.
-
-3. **```my_device_key_pub_sign.jwt```**<br>
-   This file contains the public-only key, signed by the root key,
-   that is to be provided as authentication when an RVI node identifies
-   itself toward another. The file is stored in JSON Web Token format.
-
-
-#### Configuring RVI to use a device key
-
-The RVI node needs the device private/public key root key, stored in
-```my_device_key_priv.pem```, is referenced from the RVI's configuration
-file in ```{ rvi_core, { key_pair, "..../my_device_key_priv.pem" }}```.
-
-
-### Provisioning a certificate
-
-#### Creating the certificate file
-A certificate is a JWT-formatted JSON structure signed by the root
-private key, is stored on an RVI node to be presented to remote node
-as evidence that the sender has the right to invoke and register the
-specified services.
-
-The certificate is created by the following command
-
-    ./rvi_create_certificate.py --id=my_cert_id \
-                            --device_key=my_device_key_pub.pem \
-                            --start='2015-12-01 00:00:00' \
-                            --stop='2015-12-31 23:59:59' \
-                            --root_key=my_root_key_priv.pem \
-                            --register='jlr.com/vin/abc/unlock jlr.com/vin/abc/lock' \
-                            --invoke='jlr.com/backend/report jlr.com/backend/set_state' \
-                            --jwt_out=my_cert.jwt \
-							--cert_out=my_cert.json \
-                            --issuer=jaguarlandrover.com
-
-The following arguments are provided
-* **```--id=my_cert_id```**<br>
-  System-wide unique ID to be assigned to this certificate.
-
-* **```--device_key=my_device_key_pub.pem```**<br>
-  Specifies that the public device key, generated by ```create_device_key.py```
-  shall be embedded into the generated certificate as the certificate owner.
-
-* **```--root_key=my_root_key_priv.pem```**<br>
-  Specifies that the certificate shall be signed by the private root
-  key generated by ```create_root_key.sh```.
-
-* **```--invoke='jlr.com/backend/report jlr.com/backend/set_state'```**<br>
-  Gives the device with the certificate-embedded public key the right to invoke
-  the services ```jlr.com/backend/report``` and ```jlr.com/backend/set_state```.
-
-* **```--register='jlr.com/vin/abc/unlock jlr.com/vin/abc/lock'```**<br>
-  Gives the device with the certificate-embedded public key the right to register
-  the services ```jlr.com/backend/report``` and ```jlr.com/backend/set_state```.
-
-* **```--start='2015-12-01 00:00:00'```**<br>
-  Specifies that the certificate shall become valid Dec 1, 2015 at
-  midnight.
-
-* **```--stop='2015-12-31 23:59:59'```**<br>
-  Specifies that the certificate shall expire valid Dec 31, 2015 at
-  11:59:59 PM.
-
-* **```--jwt_out=my_cert.jwt```**<br>
-  Specifies the name of the JWT file that is to be written with the
-  certificate signed by the root key in ```my_root_key_priv.pem```.
-
-* **```--cert_out=my_cert.json```**<br>
-  Specifies a file to write a JSON-formatted copy of the certificate into.
-  This file is for human inspection only and is not used by RVI or any other
-  scripts.
-
-* **```--issuer=jaguarlandrover.com```**<br>
-  Specifies that the certificate issuer is ```jaguarlandrover.com```.
-  This value is currently not used.
-
-
-Once executed, one mandatory and one optional file will be created:
-
-1. **```my_cert.jwt```**<br>
-   This file contains the generated certificate, signed by the
-   private root key specified by ```--root_key=```. The content
-   of this file will be provided by an RVI node to prove its righ
-   to register and invoke services toward remote RVI nodes
-
-
-2. **```my_cert.json```**<br>
-   Only created if ```--cert_out=``` has been give. Contains a human
-   readable JSON form of the generated root key.
-
-
-#### Configuring RVI to use a certificate
-The RVI node needs the certificates to prove its right to register and invoke
-services toward remote nodes. The generated
-certificate file, ```my_cert.jwt```, is placed in a directory with other
-certificates owned by the device.
-
-The certificate directory itself is referenced from the RVI's
-configuration file in ```{ rvi_core, { cert_dir, "...." }}```.
-
-
-
-
-## DEVICE SELF PROVISIONING THROUGH ONE-TIME TOKENS
-
-This chapter describes a yet-to-be-implemented procedure
-for provisioning new devices that are created outside
-the control of the provisioning server.
-
-### Initial provisioning at app install
-An device-specific key pair is generated by device and stored locally.
-
-The app has one pre-provisioned certificate, signed by the
-root server, allowing it to invoke ```jlr.com/provisioning/init_setup```
-and ```jlr.com/provisioning/request_provisioning```. The certificate also
-provides the right to register ```jlr.com/mobile/*/dm/cert_provision```
-and ```jlr.com/mobile/*/dm/signed_pub_key_provision```
-The certificate keys section, normally holding public device
-keys, is empty.
-
-The device has the public root key pre-provisioned.
-
-The device has the BT/IP/SMS address of its provisioning server to
-setup an initial contact.
-
-### Device self provisioning process
-**BROKEN WILL BE REDESIGNED**
-
-1. Device connects to provisioning server<br>
-   The app is started for the first time and connects to the
-   provisioning server.
-
-2. Device sends authenticate to server<br>
-   The command contains no key, only a single pre-provisioned node certificate giving
-   the device the right to invoke and register the functions listed in
-   above.<br>
-
-3. Server sends authenticate to device<br>
-   The server's public device key, signed by the root private key, is
-   sent together with no node certificates, thus giving the server no
-   rights to register or invoke services with the device.
-
-4. Device sends a service announce to server<br>
-   After validating server authenticate package, the device
-   sends a service announce to the server.
-   The command contains the services ```jlr.com/mobile/1234/dm/cert_provision```
-   and  ```jlr.com/mobile/1234/dm/signed_pub_key_provision```,
-   which can be invoked by the provisioning service to install a new
-   certificate and signed public device key on the device.
-
-5. Server sends a service announce to device<br>
-   The announcement contains the services ```jlr.com/provisioning/init_setup```
-   and```jlr.com/provisioning/request_provisioning``` .
-
-6. Device invokes ```jlr.com/provisioning/init_setup``` on server<br>
-   The sole argument is the device ID, e.g. 1234.  The command is
-   validated by the server through the pre-provisioned cert. Since
-   the cert contains no device public key, any device can invoke it.
-
-7. Sideband token transmission from provisioning service to device<br>
-   The provisioning server transmits a 128 bit random token to the device
-   using a sideband channel such as SMS or similar.
-
-8. Device invokes ```jlr.com/provisioning/request_provisioning``` on server<br>
-   The device provides its public key, and the token received in step 7 as
-   arguments to the call.
-
-9. Provisioning service signs device public key<br>
-   The provisioning service checks that the token has not expired.<br>
-   The provisioning service checks that the token has not already been used.<br>
-   The public key provided in step 8 is signed by the root private key.
-
-10. Provisioning service creates node certificates<br>
-    The created cert gives the holder the right to invoke ```jlr.com/vin/ABCD/unlock```.<br>
-    The certificate also gives the holder the right to register ```jlr.com/mobile/1234/status.```<br>
-    The certificate includes the device public key provided in step 8.
-    The certificate is signed by the private root key.<br>
-
-11. Provisioning service invokes ```jlr.com/mobile/1234/dm/signed_pub_key_provision```<br>
-    The provisioning service invokes key provisioning service on
-    the device, announced by the device to the service in step 4, to
-    install the signed public device key on the device.<br>
-	The key, signed in step 9, is provided as a single argument.
-	The device matches the key with its existing key.<br>
-	The device validates the signature using the pre-provisioned public root key.<br>
-	The device stores the signed public key to be used in future authentication messages.
-
-12. Provisioning service invokes ```jlr.com/mobile/1234/dm/cert_provision```<br>
-    The provisioning service invokes certificate provisioning service on
-    the device, announced by the device to the service in step 4, to
-    install the certificate created in step 10.<br>
-	The device matches the public key of the certificate against its own public key<br>
-	The device validates the signature using the pre-provisioned public root key.<br>
-	The device stores the signed certificate to be used in future authentication messages.
-
-
-## DEVICE - VEHICLE SESSION USE CASE
-
-In this use case, a mobile device, with ID 1234, connects to a
-vehicle, with VIN ABCD, to unlock it.
-
-The vehicle has a service, registered as ```jlr.com/vin/ABCD/request_unlock```, which
-unlocks the door.
-
-The mobile device has a service, registered as ```jlr.com/mobile/1234/confirm_unlock```,
-which updates the UI with the current state of the door locks.
-
-The device will invoke ```jlr.com/vin/ABCD/request_unlock``` to unlock the
-doors of the vehicle, while the vehicle will confirm its new unlocked
-state through a invocation to ```jlr.com/mobile/1234/confirm_unlock```
-
-1. Device 1234 connects to vehicle ABCD<br>
-   Connection is done over bluetooth, with no Internet connection.
-
-2. Device sends authenticate to vehicle<br>
-   The command contains the root-signed public device key from step 11 in the previous chapter.<br>
-   The command contains the root-signed certificate from step 12 in the previous chapter.<br>
-   The vehicle verifies the public device key signature using the pre-provisioned public root key.<br>
-   The vehicle verifies the certificate signature using the pre-provisioned public root key.<br>
-   The vehicle marks the device as being allowed to invoke ```jlr.com/vin/ABCD/request_unlock```<br>
-   The vehicle marks the device as being allowed to register ```jlr.com/mobile/1234/confirm_unlock```<br>
-
-3. Vehicle sends authenticate to device<br>
-   The command contains a root-signed public device key for the vehicle
-   The command contains a root-signed certificate, allowing the
-   vehicle to invoke ```jlr.com/vin/*/confirm_unlock```, and
-   register ```jlr.com/vin/ABCD/request_unlock```.<br>
-   The device verifies the public device key signature using the pre-provisioned public root key.<br>
-   The device verifies the certificate signature using the pre-provisioned public root key.<br>
-   The device marks the vehicle as being allowed to invoke ```jlr.com/mobile/1234/confirm_unlock```<br>
-   The device marks the vehicle as being allowed to register ```jlr.com/vin/ABCD/request_unlock```<br>
-
-
-4. Device sends service announce to vehicle<br>
-   The command contains ```jlr.com/mobile/1234/confirm_unlock```.<br>
-   Vehicle validates that the vehicle has the right to register this
-   service against the certificate received in step 2.
-
-5. Vehicle sends service announce to device<br>
-   The command contains the service ```jlr.com/vin/ABCD/request_unlock```.<br>
-   Device validates the registration against right to register services
-   listed in certificate received in step 3.<br>
-
-
-6. Device invokes ```jlr.com/vin/ABCD/request_unlock``` on vehicle<br>
-   The command, signed by the device private key, tells the
-   vehicle to unlock its doors.<br>
-   The certificate transmitted in step 2 proves that the device
-   has the right to invoke the command on the vehicle.<br>
-   The vehicle validates the signature using the public key in
-   the certificate transmitted in step 2.<br>
-   The vehicle unlocks the doors.
-
-7. Vehicle invokes ```jlr.com/mobile/1234/confirm_status``` on device<br>
-   The command, signed by the vehicle private key, acknowledges
-   to the device that the doors have been unlocked.<br>
-   The certificate transmitted in step 3 proves that the vehicle
-   has the right to invoke the command on the device.<br>
-   The device validates the signature using the public key in
-   the certificate transmitted in step 3.<br>
-   The device updates its UI with an unlocked icon.
-
-
-
-### Thwarting malicious RVI nodes - Illegal service invocation
-
-1. [standard session setup]<br>
-
-2. Device sends authenticate command to server<br>
-   The command contains the device key together with a certificate showing
-   that the device has the right to register register ```jlr.com/mobile/1234/receive_bitcoin```.
-
-3. [server validates and responds with its own authenticate]<br>
-
-4. Device sends false service announce to server<br>
-   The commands contains the service ```jlr.com/mobile/9999/receive_bitcoin```.
-
-5. Server rejects the service announce<br>
-   Since the announced service does not match the right-to-invoke section in the
-   certificate received in step 2, the announcement is rejected and no
-   invocations to ```jlr.com/mobile/9999/receive_bitcoin``` will be routed to
-   device.
-
-### Thwarting malicious RVI nodes - Stolen certificates
-1. [standard session setup]<br>
-
-2. Device sends authenticate command to server<br>
-   The command contains the root-signed public device key together
-   with a *stolen* certificate, also root signed, showing that the device has the right
-   to register register ```jlr.com/mobile/1234/receive_bitcoin```.<br>
-
-3. Server fails to validate certificate<br>
-   Server tries to match public key in stolen, root signed certificate against the
-   root signed public key in the authenticate, and fails.<br>
-   Server disconnects.
-
-### Thwarting self-provisioning process - Replay TBD.
-
-The provisioning server, having matched the side band address (MSISDN) against an internal database of devices and their access rights, will create a specific certificate only for that device.
-
-Given that the side band network has not been compromised, I can't see how a MITM / replay attack can give a remote remote attacker the ability to gain access of the root-signed public device key and/or use a certificate.
-
-The token is sent as side band data to the correct device.
-
-The device presents token and public key when it invokes the server's request_provisioning service, proving that it has received the token.
-
-The server signs the public key, proven to be received from the correct device, and invoke the device's key_provision service to store it. The request is signed by the private root key, proving to the server is not spoofed.
-
-### Thwarting self-provisioning process - Cloned phone
-
-## KEY LIFECYCLE MANAGEMENT
-TBD
+and ```insecure_credential.jwt``` are checked into ```priv/credentials```.
diff --git a/doc/rvi_services.md b/doc/rvi_services.md
index 74f92ee..11d77da 100644
--- a/doc/rvi_services.md
+++ b/doc/rvi_services.md
@@ -1,10 +1,14 @@
+<style type="text/css" media="print">
+  div.pagebreak
+  {
+    page-break-before: always;
+  }
+</style>
 Copyright (C) 2014, 2015 Jaguar Land Rover
 
 This document is licensed under Creative Commons
 Attribution-ShareAlike 4.0 International.
 
-
-
 Remote Vehicle Interface (RVI) Core Services
 ============================================
 
@@ -105,6 +109,7 @@ The parameters are:
   
 After receiving a key the device will typically store it in its key store.
 
+<div class="pagebreak"></div>
 
 ##### Provision Certificate
 
@@ -154,6 +159,8 @@ The parameters are:
 After receiving an erase certificate request the device must remove it from its
 certificate store.
 
+<div class="pagebreak"></div>
+
 ##### Clear Certificates
 
 Erase all certificates from the device's certificate store.
@@ -207,7 +214,7 @@ reject that certificate as invalid.
 
 Services to manage device configuration.
 
-##### Read Congfiguration Variables
+##### Read Configuration Variables
 
 Retrieve the value of one or more configuration variables from the device.
 
@@ -251,7 +258,9 @@ The parameters are:
 * variables - An array of dictionaries with variable names and values.
 * value - The value of the variable.
 
-##### Write Congfiguration Variables
+<div class="pagebreak"></div>
+
+##### Write Configuration Variables
 
 Set the value of one or more configuration variable in the device.
 
@@ -305,7 +314,9 @@ Sequence of events:
 5. After the server has sent the last chunk it sends `finish` to the client.
 6. Once the client receives the `finish` message and has assembled and verified
    the download it sends `download_complete` to the server with a status indicator.
-   
+
+<div class="pagebreak"></div>
+
 #### Notify
 
 Inform client of pending file transfer.
@@ -353,6 +364,8 @@ The parameters are:
           match the ID from the `notify` message this message is sent in response
           to.
 
+<div class="pagebreak"></div>
+
 #### Start Download
 
 Initiate the download from the server to the client.
@@ -398,6 +411,8 @@ The parameters are:
           may not arrive in order.
 * msg - File chunk encoded with base64.
 
+<div class="pagebreak"></div>
+
 #### Finish Transmission
 
 Indication by the server to the client that the last chunk has been sent.
@@ -441,6 +456,8 @@ The parameters are:
           match the ID from the `notify` message this message is sent in response
           to.
 
+<div class="pagebreak"></div>
+
 #### Cancel Download
 
 Tell server to cancel the download.
@@ -488,7 +505,9 @@ The parameters are:
 
 * channels - An array with the data channels to subscribe to.
 * reporting_interval - The reporting interval in milliseconds [ms].
-  
+
+<div class="pagebreak"></div>
+
 #### Unsubscribe
 
 Unsubscribe from one of more data channels. This message is typically implemented
@@ -544,6 +563,8 @@ The parameters are:
    JSON data type. In particular `value` can be a dictionary in itself, as it is
    with the `location` channel.
 
+<div class="pagebreak"></div>
+
 Currently defined channels:
 
 | Channel   | Description                | Value Data Type                    |
@@ -595,7 +616,8 @@ The parameters are:
   ```r2_lt``` and ```r2_rt``` are row two (rear) doors.<br>
   ```trunk``` is the rear trunk.<br>
   ```hood``` is the rear hood.
-  
+
+<div class="pagebreak"></div>
 
 #### Start / Stop Engine
 
@@ -640,6 +662,8 @@ The parameters are:
   ```open``` open the trunk.<br>
   ```close``` close the trunk.
 
+<div class="pagebreak"></div>
+
 #### Horn
 Activate the horn.
 
@@ -815,6 +839,8 @@ will be listed.
         }
     } 
 
+<div class="pagebreak"></div>
+
 The parameters are:
 
 * windows - List each window with its current position.
diff --git a/packaging/README.md b/packaging/README.md
index 798f0a7..ec3e8a1 100644
--- a/packaging/README.md
+++ b/packaging/README.md
@@ -72,7 +72,7 @@ Go to the top directory of RVI and execute:
 An RPM file will be generated at the end of the build which can be
 installed on a Tizen box. The RPM can be found at:
 
-    ~/GBS-ROOT/local/repos/tizen/i586/RPMS/rvi-0.4.0-1.i686.rpm
+    ~/GBS-ROOT/local/repos/tizen/i586/RPMS/rvi-0.5.0-1.i686.rpm
 
 
 # UPDATING REBAR DEPENDENCIES
diff --git a/packaging/rvi_core.spec b/packaging/rvi_core.spec
index eb37957..b692e8d 100755
--- a/packaging/rvi_core.spec
+++ b/packaging/rvi_core.spec
@@ -1,10 +1,10 @@
 Summary:    Remote Vehicle Interaction Node, running on top of Erlang,
 Name:       rvi_core
-Version:    0.4.0
+Version:    0.5.0
 Release:    1
 Group:      App Framework/Application Communication
 License:    Mozilla Public License 2.0
-Source:     http://content.linuxfoundation.org/auto/downloads/rvi/rvi_core-0.4.0.tgz
+Source:     http://content.linuxfoundation.org/auto/downloads/rvi/rvi_core-0.5.0.tgz
 
 BuildRequires:  make
 BuildRequires:  glib2-devel
@@ -50,4 +50,4 @@ rm -rf $RPM_BUILD_ROOT
 %attr(644,app,users) /home/app/content/Documents/vin
 /usr/lib/systemd/system/rvi.service 
 /etc/systemd/system/multi-user.target.wants/rvi.service
-/opt/rvi-0.4.0
+/opt/rvi-0.5.0
diff --git a/priv/sample_certificates/insecure_device_cert.crt b/priv/certificates/insecure_device_cert.crt
index efecf2a..efecf2a 100644
--- a/priv/sample_certificates/insecure_device_cert.crt
+++ b/priv/certificates/insecure_device_cert.crt
diff --git a/priv/sample_certificates/insecure_root_cert.crt b/priv/certificates/insecure_root_cert.crt
index 0f7b921..0f7b921 100644
--- a/priv/sample_certificates/insecure_root_cert.crt
+++ b/priv/certificates/insecure_root_cert.crt
diff --git a/priv/config/rvi_common.config b/priv/config/rvi_common.config
index 87563e7..c8aa389 100644
--- a/priv/config/rvi_common.config
+++ b/priv/config/rvi_common.config
@@ -115,10 +115,10 @@ LogLevel = Env("RVI_LOGLEVEL", info).
    %% },
    {rvi_core,
     [
-     {device_key, "$PRIV_DIR/sample_keys/insecure_device_key.pem"},
-     {device_cert, "$PRIV_DIR/sample_certificates/insecure_device_cert.crt"},
-     {root_cert, "$PRIV_DIR/sample_certificates/insecure_root_cert.crt"},
-     {cred_dir, "$PRIV_DIR/sample_credentials"}
+     {device_key, "$PRIV_DIR/keys/device_key.pem"},
+     {device_cert, "$PRIV_DIR/certificates/device_cert.crt"},
+     {root_cert, "$PRIV_DIR/certificates/root_cert.crt"},
+     {cred_dir, "$PRIV_DIR/credentials"}
     ]}
   ]}
 ].
diff --git a/priv/config/rvi_sample.config b/priv/config/rvi_sample.config
index 57ffd37..a178c2d 100644
--- a/priv/config/rvi_sample.config
+++ b/priv/config/rvi_sample.config
@@ -8,8 +8,6 @@
 %%
 %% Configuration file for the (in-vehicle) IVI used by the hvac_demo
 %%
-%% See ../hvac_demo/README.md for details on the demo.
-%%
 %% See ../CONFIGURE.md for a details on the configuration process
 %% itself.
 %%
@@ -195,7 +193,7 @@ LogLevel = Env("RVI_LOGLEVEL", notice).
 	  %% to the targeted service. If a pair reports a failure, the next pair is tried.
 	  [
 	   { proto_json_rpc, { dlink_tcp_rpc,
-			                   % {"38.129.64.13", 8807}
+			                   %% {"38.129.64.13", 8807}
 			       [ { target, IPPort(BackendIP, BackendPort) } ]}}
 	  ]
 	},
diff --git a/priv/config/rvi_ubuntu.config b/priv/config/rvi_ubuntu.config
new file mode 100644
index 0000000..57ffd37
--- /dev/null
+++ b/priv/config/rvi_ubuntu.config
@@ -0,0 +1,346 @@
+%% -*- erlang -*-
+
+%% Copyright (C) 2014, Jaguar Land Rover
+%%
+%% This program is licensed under the terms and conditions of the
+%% Mozilla Public License, version 2.0.  The full text of the
+%% Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+%%
+%% Configuration file for the (in-vehicle) IVI used by the hvac_demo
+%%
+%% See ../hvac_demo/README.md for details on the demo.
+%%
+%% See ../CONFIGURE.md for a details on the configuration process
+%% itself.
+%%
+
+%% Parameters for simpler modification
+Env = fun(V, Def) ->
+	      case os:getenv(V) of
+		  false -> Def;
+		  Str when is_integer(Def) -> list_to_integer(Str);
+		  Str when is_atom(Def) -> list_to_atom(Str);
+		  Str -> Str
+	      end
+      end.
+IPPort = fun(IP, Port) ->
+		 IP ++ ":" ++ integer_to_list(Port)
+	 end.
+MyPort = Env("RVI_PORT", 9000).
+MyIP = Env("RVI_MYIP", "127.0.0.1").
+MyNodeAddr = Env("RVI_MY_NODE_ADDR", IPPort(MyIP, MyPort)).
+BackendIP = Env("RVI_BACKEND", "38.129.64.31").
+BackendPort = Env("RVI_BACKEND_PORT", 8807).
+LogLevel = Env("RVI_LOGLEVEL", notice).
+
+[
+ %% All erlang apps needed to fire up a node. Do not touch.
+ {include_lib, "rvi_core/priv/config/rvi_common.config"},
+
+ %%
+ %% Custom environment settings
+ %% for all apps running on the node.
+ %%
+ {env,
+  [
+
+   %% All RVI configuration is done here.
+   %%
+   %% Please note that the rvi_node.sh launch script
+   %% can still override the port range and static nodes
+   %% through its command line parameters.
+   %%
+   %% Value substitution:
+   %% All string values under the rvi tuple tree are scanned
+   %% for specific dokens during startup. If a token is
+   %% found, it will be replaced with a value referenced by it.
+   %% Tokens can one of the following:
+   %%
+   %% $rvi_file(FileName,Default) - File content
+   %%   When an $rvi_file() token is encountered, the first line of
+   %%   the referenced file is read. The line (without the newline)
+   %%   replaces the token.
+   %%
+   %%   Example:
+   %%     { node_service_prefix, "jlr.com/vin/$rvi_file(/etc/vin,default_vin)"},
+   %%
+   %%     will be substituted with the first line from the file
+   %%     /etc/vin:
+   %%
+   %%     { node_service_prefix, "jlr.com/vin/2GKEG25HXP4093669"},
+   %%
+   %%     If /etc/vin cannot be opened, the value default_vin
+   %%     will be used instead.
+   %%
+   %%
+   %% $rvi_env(EnvironemtnName,Default) - Environment variable
+   %%   When an $rvi_env() token is encountered, the value of
+   %%   the Linux process environment variable (such as $HOME) is read
+   %%   to replace the token.
+   %%
+   %%   Example:
+   %%     { node_service_prefix, "jlr.com/vin/$rvi_env(VIN,default_vin)"},
+   %%
+   %%     will be substituted with the value of the $VIN environment
+   %%     variable:
+   %%
+   %%     { node_service_prefix, "jlr.com/vin/2GKEG25HXP4093669"},
+   %%
+   %%     If VIN is not a defined environment variable, the value
+   %%     default_vin will be used instead.
+   %%
+   %%
+   %% $rvi_uuid(Default) - Unique machine identifier
+   %%   When an $rvi_uuid() token is encountered, the UUID of the root
+   %%   disk used by the system is read to replace the token.
+   %%   The UUID of the root disk is retrieved by opening /proc/cmdline
+   %%   and extracting the root=UUID=[DiskUUID] value.
+   %%   This value is generated at system install time and is reasonably
+   %%   world wide unique.
+   %%
+   %%   Example:
+   %%     { node_service_prefix, "jlr.com/vin/$uuid(default_vin)"},
+   %%
+   %%     will be substituted with the value of the root disk UUID:
+   %%
+   %%     { node_service_prefix,
+   %%       "jlr.com/vin/afc0a6d8-0264-4f8a-bb3e-51ff8655b51c"},
+   %%
+   %%     If the root UUID cannot be retrieved, the value default_vin
+   %%     will be used instead.
+   %%
+
+   {rvi_core,
+    [
+     %% Specify the node address that data_link uses to listen to
+     %% incoming traffic from other rvi nodes.
+     %%
+     %% This is the address that is announced to
+     %% other rvi nodes during service discovery and should be
+     %% forwarded through firewalls and port forwarding to to the port
+     %% specified by the configuration entry rvi -> components ->
+     %% data_link ->json_rpc_server (see below).
+     %%
+     %% If this node is sitting behind a firewall and cannot
+     %% receive incomign connections on any address, its
+     %% node_address should be set to "0.0.0.0:0" to inform
+     %% the remote node that it should not attempt to
+     %% connect back to self.
+     { node_address, MyNodeAddr },
+
+     %% Specify the prefix of all services that this rvi node is hosting.
+     %%
+     %% All local services regsitering with service edge will be prefixed with
+     %% the string below when they are announced to remote rvi nodes
+     %% that connect to this node (using the address specified
+     %% by node_address above).
+     %%
+     %% If a locally connected service registers itself as
+     %% "hvac/fan_speed", and the node_service_prefix is
+     %% "jlr.com/vin/1234/", this node will announce the service
+     %% "jlr.com/vin/1234/hvac/fan_speed" as being available
+     %% to remotely connected rvi nodes.
+     %%
+     %% Two rvi nodes should never have the same node_service_prefix
+     %% value unless all services add a system-wide unique name
+     %% to it.
+     %%
+     { node_service_prefix, "jlr.com/vin/$rvi_uuid(default_vin)/"},
+
+
+     %% Routing rules determine how to get a message targeting a specific
+     %% service to its destination.
+     %%
+     %% Please note that if a remotely initiated (== client) data link is
+     %% available and has announced that the targeted service is available,
+     %% that data link will be used regardless of what it is.
+     %%
+     %% In other words, if you setup routing rules for how to reach out
+     %% to a vehicle using SMS, and that vehicle happens to have a 3G
+     %% connection up when the message is sent, the 3G connection will be used.
+     %%
+     %% We will add a blacklist feature in the future to optionally block
+     %% such opportunistic routing in the future.
+     %%
+     { routing_rules,
+       [
+	%% Service name prefix that rules are specified for
+	%% The service prefix with the longest match against the service targeted
+	%% by the message will be used.
+	%%
+	%% Example: Targeted service = jlr.com/backend/sota/get_updates
+	%%
+	%% Prefix1: { "jlr.com/backend", [...]}
+	%% Prefix2: { "jlr.com/backend/sota", [...]}
+	%%
+	%% Prefix2 will be used.
+	%%
+	%% This allows you, for example, to setup different servers
+	%% for different types of services (SOTA, remote door unlock,
+	%% HVAC etc).
+	%%
+
+	%% Make sure to have a default if you don't want your message
+	%% to error out immediately. With a default the message will
+	%% be queued until it times out, waiting for a remote node
+	%% to connect and announce that it can handle the targeted service.
+	{ "",
+	  [
+	   { proto_json_rpc, dlink_tcp_rpc}
+	  ]
+	},
+
+	{ "jlr.com/backend/",
+	  %% Which protocol and data link pair to use when transmitting the message
+	  %% to the targeted service. If a pair reports a failure, the next pair is tried.
+	  [
+	   { proto_json_rpc, { dlink_tcp_rpc,
+			                   % {"38.129.64.13", 8807}
+			       [ { target, IPPort(BackendIP, BackendPort) } ]}}
+	  ]
+	},
+
+	%% Used to communicate with vehicles
+	{ "jlr.com/vin/",
+	  [
+	   { proto_json_rpc, { dlink_tcp_rpc, [ broadcast, { interface, "wlan0" } ] } },
+	   { proto_json_rpc, { server_3g, [ initiate_outbound ]} },
+
+	   %% Protocols can have hinting as well.
+	   %% In this case JSON-RPC should only be used if the
+	   %% resulting message size can fit in an SMS (140 bytes).
+
+	   { { proto_json_rpc, [ { max_msg_size, 140 } ] } , server_sms }
+	  ]
+	}
+       ]
+     },
+
+     { components,
+       [
+	%% A note about JSON-RPC calls vs gen_server calls:
+	%%
+	%% All locally connected services communicate with Service Edge
+	%% through JSON-RPC.
+	%%
+	%% Communication between the internal RVI components, however,
+	%% can be either JSON-RPC or gen_server calls.
+	%%
+	%% JSON-RPC calls provide compatability with replacement components
+	%% written in languages other than Erlang.
+	%%
+	%% Gen_server calls provide native erlang inter-process calls that
+	%% are about 4x faster than JSON-RPC when transmitting large data volumes.
+	%%
+	%% If one or more of the components below are replaced with external
+	%% components, use JSON-RPC by specifying IP address and port in
+	%% json_rpc_address for all interfaced by the external components.
+	%%
+	%% If you are running an all-native erlang system, use gen_server calls
+	%% by specifying gen_server for all components
+	%%
+	%% Please note that communication between two RVI nodes are
+	%% not affected by this since dlink_tcp will use
+	%% JSON-RPC to communicate ( using the address/port specified
+	%% by proto_json_rpc).
+	%%
+
+	{rvi_common,
+	 [
+	  {rvi_log, gen_server,
+	   [{json_rpc_address, MyPort+9}]
+	  }
+	 ]},
+	%% Service_edge.
+	%% The service_edge tuple is a top level configuration
+	%% container for everything about service edge.
+	%% In theory, we can support multiple different service edge
+	%% components (written in different languages).
+	%%
+	%% However, until we've sorted out internal routing, we will
+	%% only support the native service_edge_rpc component,
+	%% accessed either as a gen_server or through JSON-RPC.
+	%%
+	{service_edge,
+	  [
+	    %% Service_edge_rpc component is used as a gen_server
+	    { service_edge_rpc, gen_server,
+	    [
+	      %% JSON-RPC address will be translated to
+	      %% an URL looking like this:
+	      %% http://127.0.0.1:8801
+	      %%
+	      %% This URL is used both for communication with
+	      %% locally connected services and for intra-component
+	      %% communication in case the access method for
+	      %% service_edge_rpc is specified as json_rpc.
+	      { json_rpc_address, { MyIP, MyPort+1 } },  % {"127.0.0.1",8801}
+	      { msgpack_rpc_address, { MyIP, MyPort + 21 } },
+
+	      %% Websocket is used for websocket access, preferably
+	      %% through the rvi.js package available for Javascript
+	      %% apps in browsers and crosswalk who wants to interface
+	      %% RVI.
+	      { websocket, [ { port, MyPort+8}]}  % 9008
+	    ]
+	    }
+	  ]
+	},
+	{ service_discovery,
+	  [ { service_discovery_rpc, gen_server,
+	      [
+	       { json_rpc_address, { MyIP, MyPort+2 }} % {"127.0.0.1",9002}
+	      ]
+	    }
+	  ]
+	},
+	{ schedule,
+	  [ { schedule_rpc, gen_server,
+	      [
+	       { json_rpc_address, { MyIP, MyPort+3 }}  % {"127.0.0.1",9003}
+	      ]
+	    }
+	  ]
+	},
+	{ authorize,
+	  [ { authorize_rpc, gen_server,
+	      [
+		{ json_rpc_address, { MyIP, MyPort+4 } } % {"127.0.0.1",9004}
+	      ]
+	    }
+	  ]
+	},
+	{ protocol,
+	  [ { proto_json_rpc, gen_server,
+	      [
+		{ json_rpc_address, { MyIP, MyPort+5 } } % {"127.0.0.1",9005}
+	      ]
+	    }
+	  ]
+	},
+	{ data_link,
+	  [ { dlink_tcp_rpc, gen_server,
+	      [
+		{ json_rpc_address, { MyIP, MyPort+6 } },  % 9006
+		%% data link TCP server specifies the port we should
+		%% listen to for incoming connections
+		%% from other rvi nodes.
+		%% A specific NIC address can also be specified
+		%% through the {ip, "192.168.0.1" } tuple.
+		{ server_opts, [ { port, MyPort+7 }]},
+		{ persistent_connections, [ IPPort(BackendIP, BackendPort) ]}
+	      ]
+	    },
+	    { dlink_tls_rpc, gen_server,
+	      [
+	       { json_rpc_address, { MyIP, MyPort+11} },
+	       { server_opts, [ {port, MyPort+10} ]}
+	      ]
+	    }
+	  ]
+	}
+       ]
+     }
+    ]}
+  ]}
+].
diff --git a/priv/sample_credentials/insecure_credential.json b/priv/credentials/insecure_credential.json
index 5788a06..5788a06 100644
--- a/priv/sample_credentials/insecure_credential.json
+++ b/priv/credentials/insecure_credential.json
diff --git a/priv/sample_credentials/insecure_credential.jwt b/priv/credentials/insecure_credential.jwt
index 0ce62ab..0ce62ab 100644
--- a/priv/sample_credentials/insecure_credential.jwt
+++ b/priv/credentials/insecure_credential.jwt
diff --git a/priv/sample_keys/insecure_device_key.pem b/priv/keys/insecure_device_key.pem
index 404af0a..404af0a 100644
--- a/priv/sample_keys/insecure_device_key.pem
+++ b/priv/keys/insecure_device_key.pem
diff --git a/priv/sample_keys/insecure_root_key.pem b/priv/keys/insecure_root_key.pem
index b9e2e3f..b9e2e3f 100644
--- a/priv/sample_keys/insecure_root_key.pem
+++ b/priv/keys/insecure_root_key.pem
diff --git a/priv/test_config/backend.config b/priv/test_config/backend.config
index 0f49784..361b3da 100644
--- a/priv/test_config/backend.config
+++ b/priv/test_config/backend.config
@@ -6,7 +6,6 @@
   [
    {rvi_core,
     [{device_key, "$HOME/../../basic_backend_keys/device_key.pem"},
-     {provisioning_key, "$HOME/../../root_keys/root_key.pem"},
      {root_cert, "$HOME/../../root_keys/root_cert.crt"},
      {device_cert, "$HOME/../../basic_backend_keys/device_cert.crt"},
      {cred_dir, "$HOME/../../basic_backend_creds"}
diff --git a/priv/test_config/tls_backend_noverify.config b/priv/test_config/tls_backend_noverify.config
new file mode 100644
index 0000000..cb24e81
--- /dev/null
+++ b/priv/test_config/tls_backend_noverify.config
@@ -0,0 +1,16 @@
+%% -*- erlang -*-
+[
+ {include_lib, "rvi_core/priv/test_config/backend.config"},
+ {set_env,
+  [
+   {rvi_core,
+    [
+     { [routing_rules, ""], [{proto_msgpack_rpc, dlink_tls_rpc}] },
+     { [components, data_link], [{dlink_tls_rpc, gen_server,
+				  [{server_opts, [{port, 8807},
+						  {verify, false},
+						  {ping_interval,500}]}]}]},
+     { [components, protocol], [{proto_msgpack_rpc, gen_server, []}] }
+    ]}
+  ]}
+].
diff --git a/priv/test_config/tls_sample_noverify.config b/priv/test_config/tls_sample_noverify.config
new file mode 100644
index 0000000..0328cf4
--- /dev/null
+++ b/priv/test_config/tls_sample_noverify.config
@@ -0,0 +1,18 @@
+%% -*- erlang -*-
+[
+ {include_lib, "rvi_core/priv/test_config/sample.config"},
+ {set_env,
+  [
+   {rvi_core,
+    [
+     { [routing_rules, ""], [{proto_msgpack_rpc, dlink_tls_rpc}] },
+     { [components, data_link], [{dlink_tls_rpc, gen_server,
+				  [{server_opts, [{port, 9007},
+%						  {verify, false},
+						  {ping_interval,500}]},
+				   {persistent_connections,
+				    ["localhost:8807"]}]}]},
+     { [components, protocol], [{ proto_msgpack_rpc, gen_server, [] }] }
+    ]}
+  ]}
+].
diff --git a/python/rvi_call.py b/python/rvi_call.py
index 746b4ee..6fb8b55 100755
--- a/python/rvi_call.py
+++ b/python/rvi_call.py
@@ -19,11 +19,11 @@ import getopt
 def usage():
     print "Usage:", sys.argv[0], "[-n RVI-node] service key=val ..."
     print "  RVI-node     DNS name or IP of host running RVI. "
-    print "               default: http://localhost:8801"
+    print "               default: http://localhost:9001"
     print "  service      Service to invoke in RVI."
     print "  key=val      Named arguments to provide to service."
     print
-    print "Example: ./callrvi.py -n http://rvi1.nginfotpdx.net:8801 \\"
+    print "Example: ./callrvi.py -n http://rvi1.nginfotpdx.net:9001 \\"
     print "                      jlr.com/vin/aaron/4711/test/ping \\"
     print "                      arg1=val1 arg2=val2"                    
 
@@ -36,7 +36,7 @@ def usage():
 opts, args= getopt.getopt(sys.argv[1:], "n:")
 
 
-rvi_node = "http://localhost:8801"
+rvi_node = "http://localhost:9001"
 for o, a in opts:
     if o == "-n":
         rvi_node = a
diff --git a/python/rvi_call_ws.py b/python/rvi_call_ws.py
index ab87d52..c897309 100755
--- a/python/rvi_call_ws.py
+++ b/python/rvi_call_ws.py
@@ -6,7 +6,7 @@ import json
 
 opts, args = getopt.getopt(sys.argv[1:], "n:")
 
-host = 'ws://localhost:8808'
+host = 'ws://localhost:9008'
 
 for o, a in opts:
     if o == "-n":
@@ -36,4 +36,4 @@ payload['params'] = {'service_name':service, 'timeout':(int(time.time())+60), 'p
 payload['id'] = "1"
 payload['method'] = 'message'
 
-ws.send(json.dumps(payload))
\ No newline at end of file
+ws.send(json.dumps(payload))
diff --git a/python/rvi_get_services.py b/python/rvi_get_services.py
index eeadcdc..100ecf0 100755
--- a/python/rvi_get_services.py
+++ b/python/rvi_get_services.py
@@ -21,9 +21,9 @@ def usage():
     print "through an RVI node."
     print
     print "Usage:", sys.argv[0], " [RVI-node]"
-    print "Default RVI node is http://127.0.0.1:8801"
+    print "Default RVI node is http://127.0.0.1:9001"
     print
-    print "Example: ./callrvi.py http://rvi1.nginfotpdx.net:8801"
+    print "Example: ./callrvi.py http://rvi1.nginfotpdx.net:9001"
     print
     sys.exit(255)
 
@@ -39,7 +39,7 @@ progname = sys.argv[0]
 if len(sys.argv) == 2:
     rvi_node = sys.argv[1]
 else:
-    rvi_node = "http://localhost:8801"
+    rvi_node = "http://localhost:9001"
 
 #
 # Setup an outbound JSON-RPC connection to the backend RVI node
diff --git a/python/rvi_service.py b/python/rvi_service.py
index 0d6ec6d..25a45c9 100755
--- a/python/rvi_service.py
+++ b/python/rvi_service.py
@@ -18,7 +18,7 @@ import getopt
 def usage():
     print "Usage:", sys.argv[0], "[-n <rvi_url>] <service_name>"
     print "  <rvi_url>                     URL of Service Edge on a local RVI node."
-    print "                                Default: http://localhost:8801"
+    print "                                Default: http://localhost:9001"
     print "  <service_name>                URL of Service to register"
     print
     print "The RVI Service Edge URL can be found in"
@@ -28,7 +28,7 @@ def usage():
     print "The Service Edge URL is also logged as a notice when the"
     print "RVI node is started."
     print
-    print "Example: ./rvi_service.py -n http://rvi1.nginfotpdx.net:8801 /test/some_service"
+    print "Example: ./rvi_service.py -n http://rvi1.nginfotpdx.net:9001 /test/some_service"
     sys.exit(255)
 
 
@@ -39,7 +39,7 @@ def usage():
 # the sender has to match the argument names.
 
 # For example:
-# rvi_call.py http://localhost:8801 jlr.com/vin/test a=1 b=2 c=3 ->
+# rvi_call.py http://localhost:9001 jlr.com/vin/test a=1 b=2 c=3 ->
 #    def service(a,b,c)
 # 
 def service_invoked(**args):
@@ -75,7 +75,7 @@ def services_unavailable(**args):
 #
 opts, args= getopt.getopt(sys.argv[1:], "n:")
 
-rvi_node_url = "http://localhost:8801"
+rvi_node_url = "http://localhost:9001"
 for o, a in opts:
     if o == "-n":
         rvi_node_url = a
diff --git a/python/rvi_service_ws.py b/python/rvi_service_ws.py
index 9ddfbf3..8d85981 100644
--- a/python/rvi_service_ws.py
+++ b/python/rvi_service_ws.py
@@ -21,14 +21,14 @@ import getopt
 def usage():
     print "Usage:", sys.argv[0], "[-n <rvi_url>] <service_name>"
     print "  <rvi_url>                     URL of Service Edge on a local RVI node."
-    print "                                Default: ws://localhost:8808"
+    print "                                Default: ws://localhost:9008"
     print "  <service_name>                URL of Service to register"
     print
     print "The Service Edge URL is logged as a notice when the"
     print "RVI node is started."
     print
    
-    print "Example: ./rvi_service_ws.py -n ws://rvi1.nginfotpdx.net:8808 /test/some_service"
+    print "Example: ./rvi_service_ws.py -n ws://rvi1.nginfotpdx.net:9008 /test/some_service"
     sys.exit(255)
 
 
@@ -39,7 +39,7 @@ def usage():
 # the sender has to match the argument names.
 
 # For example:
-# rvi_call.py http://localhost:8801 jlr.com/vin/test a=1 b=2 c=3 ->
+# rvi_call.py http://localhost:9001 jlr.com/vin/test a=1 b=2 c=3 ->
 #    def service(a,b,c)
 # 
 def service_invoked(**args):
@@ -75,7 +75,7 @@ def services_unavailable(**args):
 #
 opts, args= getopt.getopt(sys.argv[1:], "n:")
 
-rvi_node_url = "ws://localhost:8808"
+rvi_node_url = "ws://localhost:9008"
 for o, a in opts:
     if o == "-n":
         rvi_node_url = a
diff --git a/python/rvilib.py b/python/rvilib.py
index d9f2388..b284c82 100644
--- a/python/rvilib.py
+++ b/python/rvilib.py
@@ -5,7 +5,7 @@
 # Mozilla Public License, version 2.0.  The full text of the 
 # Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
 #
-# rbilib.py 0.4.0
+# rbilib.py 0.5.0
 #  
 # This moduke
 from jsonrpclib.SimpleJSONRPCServer import SimpleJSONRPCServer
diff --git a/rel/reltool.config b/rel/reltool.config
index 8c67965..bad8d3a 100644
--- a/rel/reltool.config
+++ b/rel/reltool.config
@@ -4,7 +4,7 @@
        {lib_dirs, ["../deps/", "../components/"]},
        {erts, [{mod_cond, derived}, {app_file, strip}]},
        {app_file, strip},
-       {rel, "rvi", "0.4.0",
+       {rel, "rvi", "0.5.0",
         [
          kernel,
          stdlib,
diff --git a/rpm/SPECS/rvi-0.4.0.spec b/rpm/SPECS/rvi-0.5.0.spec
index 67b4854..2eca0eb 100644
--- a/rpm/SPECS/rvi-0.4.0.spec
+++ b/rpm/SPECS/rvi-0.5.0.spec
@@ -1,12 +1,12 @@
 Summary: Remote Vehicle Interaction Node
 Name: rvi
-Version: 0.4.0
+Version: 0.5.0
 Release: 1
 # Copyright: Jaguar Land Rover -
 License: Mozilla Public License v2
 Vendor: Jaguar Land Rover
 Group: Applications/System
-Source: http://content.linuxfoundation.org/auto/downloads/rvi/rvi-0.4.0.tgz
+Source: http://content.linuxfoundation.org/auto/downloads/rvi/rvi-0.5.0.tgz
 Buildroot: /var/tmp/%{name}-buildroot
 
 # Requires: 
@@ -69,4 +69,4 @@ rm -rf $RPM_BUILD_ROOT
 /etc/rc4.d
 /etc/rc5.d
 /etc/rc6.d
-/opt/rvi-0.4.0
+/opt/rvi-0.5.0
diff --git a/scripts/rvi b/scripts/rvi
deleted file mode 100644
index 6683c52..0000000
--- a/scripts/rvi
+++ /dev/null
@@ -1,71 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2014, Jaguar Land Rover
-#
-# This program is licensed under the terms and conditions of the
-# Mozilla Public License, version 2.0.  The full text of the 
-# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
-#
-
-#
-# Setup a correct configuration and launch an RVI release node.
-# If a UUID file has not been created, it will be done at this time.
-#
-
-SELF_DIR=$(dirname $(readlink -f "$0"))
-CONFIG_DIR=/etc/opt/rvi
-BIN_DIR=/opt/rvi
-
-usage() {
-    echo "Usage: $0 -c config_file"
-    echo "  -c config_file        Specify the configuration "
-    echo "Configuration data is read from the configuration file."
-    exit 1
-}
-
-while getopts "c:" o; do
-    case "${o}" in
-        c)
-            CONFIG_FILE=${OPTARG}
-            ;;
-        *)
-            usage
-            ;;
-    esac
-done
-
-if [ -z "${CONFIG_FILE}" ] ; then
-    echo "Missing -c flag"
-    usage
-fi
-
-# Check if we have a uuid file.
-if [ ! -f ${CONFIG_DIR}/device_id ]
-then
-    echo "Creating device ID in ${CONFIG_DIR}/device_id"
-    cat /proc/sys/kernel/random/uuid > ${CONFIG_DIR}/device_id
-fi
-
-# 
-# Generate a config file that will end up as
-# /tmp/rvi/sys.config
-#
-(
-    cd /tmp/
-    rm -rf rvi
-    export ERL_LIBS=${BIN_DIR}/setup:${BIN_DIR}/lib/
-    ${BIN_DIR}/setup_gen rvi $CONFIG_FILE rvi
-)
-
-# Did we succeed with config generation?
-if [ "$?" != "0" ]
-then
-    # Nope
-    exit "$?"
-fi   
-
-# Copy created config file to /etc/opt/rvi/sys.config,
-# which is symlinked to by /opt/rvi/sys.config
-cp /tmp/rvi/sys.config /etc/opt/rvi/sys.config
-
-exec /opt/rvi/bin/rvi start
diff --git a/scripts/rvi.service b/scripts/rvi.service
deleted file mode 100644
index 1220eb9..0000000
--- a/scripts/rvi.service
+++ /dev/null
@@ -1,19 +0,0 @@
-# systemd(8) setup usde by Tizen and others.
-[Unit]
-Description=Remote Vehicle Interaction Service
-Wants=network-online.target
-
-[Service]
-Environment="HOME=/opt/rvi-0.4.0"
-Type=forking
-StandardOutput=journal
-StandardError=journal
-ExecStartPre=/usr/bin/chsmack --access User /home/app/content/Documents/vin
-ExecStartPre=/opt/rvi-0.4.0/erts-5.10.4/bin/epmd -daemon
-ExecStart=/bin/sh /opt/rvi-0.4.0/bin/rvi start
-ExecStop=/bin/sh /opt/rvi-0.4.0/bin/rvi stop
-ExecStopPost=/opt/rvi-0.4.0/erts-5.10.4/bin/epmd -kill
-GuessMainPID=yes
-
-[Install]
-WantedBy=graphical.target multi-user.target
diff --git a/scripts/rvi.service.tizen b/scripts/rvi.service.tizen
deleted file mode 100644
index 1220eb9..0000000
--- a/scripts/rvi.service.tizen
+++ /dev/null
@@ -1,19 +0,0 @@
-# systemd(8) setup usde by Tizen and others.
-[Unit]
-Description=Remote Vehicle Interaction Service
-Wants=network-online.target
-
-[Service]
-Environment="HOME=/opt/rvi-0.4.0"
-Type=forking
-StandardOutput=journal
-StandardError=journal
-ExecStartPre=/usr/bin/chsmack --access User /home/app/content/Documents/vin
-ExecStartPre=/opt/rvi-0.4.0/erts-5.10.4/bin/epmd -daemon
-ExecStart=/bin/sh /opt/rvi-0.4.0/bin/rvi start
-ExecStop=/bin/sh /opt/rvi-0.4.0/bin/rvi stop
-ExecStopPost=/opt/rvi-0.4.0/erts-5.10.4/bin/epmd -kill
-GuessMainPID=yes
-
-[Install]
-WantedBy=graphical.target multi-user.target
diff --git a/scripts/rvi.service.yocto b/scripts/rvi.service.yocto
deleted file mode 100644
index 1ddae5d..0000000
--- a/scripts/rvi.service.yocto
+++ /dev/null
@@ -1,18 +0,0 @@
-# systemd(8) setup usde by Tizen and others.
-[Unit]
-Description=Remote Vehicle Interaction Service
-Wants=network-online.target
-
-[Service]
-Environment="HOME=/opt/rvi"
-Type=forking
-StandardOutput=journal
-StandardError=journal
-ExecStartPre=epmd -daemon
-ExecStart=/bin/sh /opt/rvi/rvi.sh -d /etc/opt/rvi -c /etc/opt/rvi/rvi_yocto.config start
-ExecStop=/bin/sh /opt/rvi/rvi stop
-ExecStopPost=epmd -kill
-GuessMainPID=yes
-
-[Install]
-# WantedBy=graphical.target multi-user.target
diff --git a/scripts/rvi.sh b/scripts/rvi.sh
deleted file mode 100755
index 7b69d8d..0000000
--- a/scripts/rvi.sh
+++ /dev/null
@@ -1,192 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2014, Jaguar Land Rover
-#
-# Mozilla Public License, version 2.0.  The full text of the
-# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
-#
-#
-# Setup a correct configuration and launch an RVI release node.
-# If a UUID file has not been created, it will be done at this time.
-# Init.d script to start and stop an RVI system installed
-# through an RPM.
-#
-
-SELF_DIR=$(dirname $(readlink -f "$0"))
-
-ERL=${ERL:=erl}
-
-usage() {
-    echo "Usage: $0 -d config_dir -c config_file -l log_dir \\"
-    echo "       start|stop|console|attach|ping"
-    echo
-    echo "  -c config_file  Configuration file to launch rvi node with. "
-    echo "                  If omitted the rvi_sample.config in the configuration "
-    echo "                  directory will be used."
-    echo
-    echo "  -s short_name   Erlang node short name. Defaults to 'rvi_core'"
-    echo
-    echo "  -C cookie       Erlang node cookie to use. Defaults to 'rvi_cookue'"
-    echo
-    echo "  -d config_dir   Directory to put generated uuid 'device_id' file and"
-    echo "                  processed config files."
-    echo "                  Defauts to the '/etc/opt/rvi'."
-    echo
-    echo "  -l log_dir      The directory to store log files in."
-    echo "                  Defaults to '/tmp/rvi/[config]/log' where [config]"
-    echo "                  is the base name of the configuration file."
-    echo
-    echo "  console [defaut]  Start an rvi in foreground mode."
-    echo
-    echo "  start             Start an rvi node with the given configuration file."
-    echo
-    echo "  stop              Stop an rvi node previously started with 'start'."
-    echo
-    echo "  attach            Attach to an rvi node previously started with 'start'."
-    echo
-    echo "  ping              Ping to check if an rvi node is up. Returns 0 if up."
-    exit 1
-}
-
-CONFIG_FILE=""
-
-SNAME=rvi_core
-COOKIE=rvi_cookie
-unset CONFIG_DIR
-unset LOG_DIR
-while getopts "c:d:l:s:C:" o; do
-    case "${o}" in
-        s)
-            SNAME=${OPTARG}
-            ;;
-        c)
-            CONFIG_FILE=${OPTARG}
-            ;;
-        C)
-            COOKIE=${OPTARG}
-            ;;
-        d)
-            CONFIG_DIR=${OPTARG}
-            ;;
-        l)
-            LOG_DIR=${OPTARG}
-            ;;
-        *)
-            usage
-            ;;
-    esac
-done
-
-CONFIG_DIR=${CONFIG_DIR:=/etc/opt/rvi}
-
-shift $((${OPTIND}-1))
-
-if [ "${#}" = "0" ]
-then
-    CMD="console"
-else
-    CMD=$1
-fi
-
-if [ "${CMD}" != "start" -a "${CMD}" != "attach" -a "${CMD}" != "stop" -a  "${CMD}" != "console" -a  "${CMD}" != "ping" ]
-then
-    usage
-fi
-
-export ERL_LIBS=${SELF_DIR}/rvi_core:${SELF_DIR}/rvi_core/deps:${SELF_DIR}/rvi_core/components
-
-# Convert config dir to abs path
-if [ $(echo ${CONFIG_DIR} | cut -c 1,1) != "/" ]
-then
-    CONFIG_DIR=${PWD}/${CONFIG_DIR}
-fi
-
-# Check that we have a config dir
-if [ ! -d ${CONFIG_DIR} ]
-then
-    install -d --mode=0755 ${CONFIG_DIR}
-fi
-
-# Check if we have a uuid file.
-if [ ! -f ${CONFIG_DIR}/device_id ]
-then
-    echo "Creating device ID in ${CONFIG_DIR}/device_id"
-    cat /proc/sys/kernel/random/uuid > ${CONFIG_DIR}/device_id
-fi
-
-#
-# See if we need to process a config file
-#
-if [ ${CMD} = "start" -o ${CMD} = "console" ]
-then
-    # Default to rvi.config
-    CONFIG_FILE=${CONFIG_FILE:=${CONFIG_DIR}/rvi_sample.config}
-    #
-    # Check if we need to prepend current dir
-    # to relative config file path
-    #
-    if [ $(echo ${CONFIG_FILE} | cut -c 1,1) != "/" ]
-    then
-	CONFIG_FILE=${PWD}/${CONFIG_FILE}
-    fi
-
-    # Check that config file can be read.
-    if [ ! -r "${CONFIG_FILE}" ]
-    then
-	echo "${CONFIG_FILE} cannot be opened for reading."
-	usage
-    fi
-    #
-    # Generate a config file that will end up as
-    # /tmp/rvi/sys.config
-    #
-    (
-	cd ${CONFIG_DIR}
-	${SELF_DIR}/scripts/setup_gen rvi ${CONFIG_FILE} rvi
-    )
-
-    # Did we succeed with config generation?
-    if [ "$?" != "0" ]
-    then
-	# Nope
-	echo "Failed to process configuration file."
-	exit "$?"
-    fi
-fi
-
-TMP_DIR=/tmp/rvi/$(basename ${CONFIG_FILE} .config)
-LOG_DIR=${LOG_DIR:=${TMP_DIR}/rvi/log}
-
-if [ $(echo ${LOG_DIR} | cut -c 1,1) != "/" ]
-then
-    LOG_DIR=${PWD}/${LOG_DIR}
-fi
-
-LAUNCH="${ERL} +A 128 -boot ${CONFIG_DIR}/rvi/start -sname ${SNAME} -config ${CONFIG_DIR}/rvi/sys -setcookie ${COOKIE}"
-
-case "${CMD}" in
-   start)
-	 install -d --mode 0755  ${TMP_DIR}
-	 install -d --mode 0755  ${LOG_DIR}
-	 cd ${SELF_DIR}
-	 exec run_erl -daemon ${TMP_DIR}/ ${LOG_DIR} "exec ${LAUNCH}"
-	 ;;
-
-   console)
-       cd ${SELF_DIR}
-       exec ${LAUNCH}
-       ;;
-
-   stop)
-       exec ${SELF_DIR}/scripts/nodetool -sname ${SNAME} -setcookie ${COOKIE} stop
-       ;;
-
-   ping)
-       exec ${SELF_DIR}/scripts/nodetool -sname ${SNAME} -setcookie ${COOKIE} ping
-       ;;
-
-   attach)
-       exec to_erl ${TMP_DIR}
-       ;;
-
-esac
diff --git a/scripts/rvi_create_certificate_key.sh b/scripts/rvi_create_certificate_key.sh
deleted file mode 100755
index 6e09fdc..0000000
--- a/scripts/rvi_create_certificate_key.sh
+++ /dev/null
@@ -1,254 +0,0 @@
-#!/usr/bin/python
-
-#
-# Copyright (C) 2015, Jaguar Land Rover
-#
-# This program is licensed under the terms and conditions of the
-# Mozilla Public License, version 2.0.  T full text of the 
-# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
-#
-#  Create a certificate giving the sender the right to invoke and 
-#
-
-import getopt
-import sys
-from Crypto.PublicKey import RSA 
-
-# apt-get install python-dev
-# apt-get install libffi-dev
-# pip install cryptography
-# pip install PyJWT
-
-import jwt
-import time
-import json
-import base64
-import struct
-
-def long2intarr(long_int):
-    _bytes = []
-    while long_int:
-        long_int, r = divmod(long_int, 256)
-        _bytes.insert(0, r)
-    return _bytes
-
-# copied from https://github.com/rohe/pyjwkest
-def long_to_base64(n):
-    bys = long2intarr(n)
-    data = struct.pack('%sB' % len(bys), *bys)
-    if not len(data):
-        data = '\x00'
-    s = base64.urlsafe_b64encode(data).rstrip(b'=')
-    return s
-
-def usage():
-    print "Usage:", sys.argv[0], "--id=<id> --invoke='<services>' -register='<services>' \\"
-    print "                       --root_key=<file> --start='<date/time>' --stop='<date/time>' \\"
-    print "                       --out=<file>"
-    print
-    print "  --id=<id>                       System-wide unique certificate ID"
-    print 
-    print "  --invoke='<services>'           Right to invoke service. Space separate multiple services."
-    print 
-    print "  --register='<services>'         Right to register service. Space separate multiple services."
-    print "                                  At least one --invoke or --register must be given."
-    print 
-    print "  --root_key=<file>               Private root key to sign certificate with"
-    print "                                  Mandatory"
-    print
-    print "  --device_key=<file>             Public device key to include in certificate"
-    print "                                  Mandatory"
-    print
-    print "  --start='<YYYY-MM-DD HH:MM:SS>' Date and time when certificate is activated."
-    print "                                  Default: current time."
-    print
-    print "  --stop='<YYYY-MM-DD HH:MM:SS>'  Date and time when certificate is deactivated."
-    print "                                  Default: 365 days from current time"
-    print
-    print "  --jwt_out=<file>                File name to store JWT-encoded certificate in."
-    print "                                  Default: stdout"
-    print
-    print "  --cert_out=<file>               File name to unencoded JSON certificate in."
-    print "                                  Default: Do not store certificate"
-    print
-    print "  --issuer=issuer                 Name of the issuer. Default: jaguarlandrover.com"
-    print
-    print "Root key file is generated by rvi_create_root_key.sh"
-    print
-    print "Device key is the '_pub.pem'-suffixed file created by rvi_create_device_key.py"
-    print
-    print "Certificate file specified by out should be placed in 'priv/certs'"
-    print 
-    print
-    print "Example:"
-    print "./rvi_create_certificate.py --id=317624d8-2ccf-11e5-993c-7f3b5182c649 \\"
-    print "                            --device_key=device_key_pub.pem \\"
-    print "                            --start='2015-12-01 00:00:00' \\"
-    print "                            --stop='2015-12-31 23:59:59' \\"
-    print "                            --root_key=root_key_priv.pem \\"
-    print "                            --register='jlr.com/vin/abc/unlock jlr.com/vin/abc/lock' \\"
-    print "                            --invoke='jlr.com/backend/report jlr.com/backend/set_state' \\"
-    print "                            --jwt_out=lock_cert.jwt \\"
-    print "                            --cert_out=lock_cert.json"
-    sys.exit(255)
-
-try:
-    opts, args = getopt.getopt(sys.argv[1:], "", [ 'issuer=', 'invoke=', 'register=', 
-                                                   'root_key=', 'start=', 
-                                                   'stop=', 'cert_out=', 'id=',
-                                                   'jwt_out=', 'device_key='])
-except getopt.GetoptError as e:
-    print
-    print e
-    print
-    usage()
-
-start=int(time.time())
-stop=int(time.time()) + 86400 * 365
-
-issuer='jaguarlandrover.com'
-invoke=None
-register=None
-root_key=None
-device_key=None
-jwt_out_file=None
-cert_out_file=None
-id_string=None
-for o, a in opts:
-    if o == "--start":
-        try:
-            start = int(time.mktime(time.strptime(a, "%Y-%m-%d %H:%M:%S")))
-        except:
-            print
-            print "Incorrect start time: {}".format(a)
-            print
-            usage()
-            
-    elif o == '--root_key':
-        try:
-            root_key_fname = a
-            root_key_file = open(root_key_fname, "r")
-            root_key = RSA.importKey(root_key_file.read())
-            root_key_file.close()
-        except IOError as e:
-            print "Coould read root cert from {0}: {1}".format(a, e.strerror)
-            sys.exit(255)
-
-    elif o == '--device_key':
-        try:
-            device_key_file = open(a, "r")
-            device_key = RSA.importKey(device_key_file.read())
-            device_key_file.close()
-        except IOError as e:
-            print "Coould read root cert from {0}: {1}".format(a, e.strerror)
-            sys.exit(255)
-
-    elif o == "--stop":
-        try:
-            stop = int(time.mktime(time.strptime(a, "%Y-%m-%d %H:%M:%S")))
-        except:
-            print
-            print "Incorrect stop time: {}".format(a)
-            print
-            usage()
-
-    elif o == '--invoke':
-        invoke=a.split(' ')
-
-    elif o == '--register':
-        register=a.split(' ')
-
-    elif o == '--id':
-        id_string=a
-
-    elif o == '--issuer':
-        issuer=a
-
-    elif o == '--jwt_out':
-        try:
-            jwt_out_file = open(a, "w")
-        except IOError as e:
-            print "Coould write to JWT file {0}: {1}".format(a, e.strerror)
-            sys.exit(255)
-
-    elif o == '--cert_out':
-        try:
-            cert_out_file = open(a, "w")
-        except IOError as e:
-            print "Coould write to certificate file {0}: {1}".format(a, e.strerror)
-            sys.exit(255)
-
-    else:
-        print
-        print "Unknown command line argument: {}".format(o)
-        print
-        usage()
-        
-if jwt_out_file == None:
-    jwt_out_file = sys.stdout
-
-if not invoke and not register:
-    print
-    print "At least one --invoke or --register service must be specified."
-    print
-    usage()
-
-if not root_key:
-    print
-    print "No --root_key=<root_key_file.pem> specified"
-    print
-    usage()
-
-if not device_key:
-    print
-    print "No --device_key=<device_public_key_file.pem> specified"
-    print
-    usage()
-
-if not id_string:
-    print
-    print "No --id=<id_string> specified"
-    print
-    usage()
-
-
-# Create a JSON Web Key based off our public device key PEM file
-
-
-cert = { 
-    'iss': issuer,
-    'id': id_string,
-    'sources': register,
-    'destinations': invoke,
-    'create_timestamp': int(time.time()),
-    'keys': [{
-	"kty": "RSA",
-        "alg": "RS256",
-        "use": "sig",
-        "e": long_to_base64(device_key.e),
-        "n": long_to_base64(device_key.n)
-    }],
-    'validity': { 
-        'start': start,
-        'stop': stop
-    }
-}
-
-
-encoded = jwt.encode(cert, root_key.exportKey("PEM"), algorithm='RS256')
-
-# Validate
-try:
-    jwt.decode(encoded, root_key.publickey().exportKey("PEM"))
-except:
-    print "FAILED: Could not verify signed JSON Web Token using public part of"
-    print "        root key {}".format(root_key_fname)
-
-
-jwt_out_file.write(encoded)
-jwt_out_file.close()
-
-if cert_out_file:
-    cert_out_file.write(json.dumps(cert, sort_keys=True, indent=4, separators=(',', ': ')) + '\n')
-    cert_out_file.close()
-
diff --git a/scripts/rvi_create_device_key.sh b/scripts/rvi_create_device_key.sh
deleted file mode 100755
index 060ea8b..0000000
--- a/scripts/rvi_create_device_key.sh
+++ /dev/null
@@ -1,155 +0,0 @@
-#!/usr/bin/python
-
-#
-# Copyright (C) 2015, Jaguar Land Rover
-#
-# This program is licensed under the terms and conditions of the
-# Mozilla Public License, version 2.0.  T full text of the 
-# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
-#
-# 
-#  1. Generate a device key through openssl.
-#  2. Sign the public key using the provided private root key.
-#  3. Create a JWT version of the signed device key.
-#
-
-import getopt
-import sys
-from Crypto.PublicKey import RSA 
-import json
-import base64
-import os
-
-# apt-get install python-dev
-# apt-get install libffi-dev
-# pip install cryptography
-# pip install PyJWT
-
-import jwt
-import struct
-
-def long2intarr(long_int):
-    _bytes = []
-    while long_int:
-        long_int, r = divmod(long_int, 256)
-        _bytes.insert(0, r)
-    return _bytes
-
-# copied from https://github.com/rohe/pyjwkest
-def long_to_base64(n):
-    bys = long2intarr(n)
-    data = struct.pack('%sB' % len(bys), *bys)
-    if not len(data):
-        data = '\x00'
-    s = base64.urlsafe_b64encode(data).rstrip(b'=')
-    return s
-
-def usage():
-    print "Usage:", sys.argv[0], "-p <priv_root_key> -o <prefix> -b <bits>"
-    print "  -p <priv_root_key>  Private root key file to sign public device key with."
-    print "  -o <prefix>         File name prefix for generated device keys."
-    print "  -b <bits>           Device key length. Default 2048."
-    sys.exit(255)
-
-opts, args= getopt.getopt(sys.argv[1:], "p:o:b:")
-
-priv_root_key_fname=""
-fname_prefix=""
-key_lenth=2048
-for o, a in opts:
-    if o == "-p":
-        priv_root_key_fname = a
-    elif o == "-b":
-        key_length = int(a)
-    elif o == "-o":
-        fname_prefix = a
-    else:
-        usage()
-        
-if priv_root_key_fname == "" or fname_prefix == "":
-    usage()
-
-
-#
-# Generate the device RSA key pair
-#
-new_key = RSA.generate(bits=key_length) 
-
-
-#
-# Create private key file, which also contains the public key.
-#
-priv_key_fname = "{}_priv.pem".format(fname_prefix)
-priv_key_file = open(priv_key_fname, 'w')
-priv_key = new_key.exportKey("PEM") 
-priv_key_file.write(priv_key)
-priv_key_file.close()
-
-
-# Read the root private key
-priv_root_key_file = open(priv_root_key_fname, 'r')
-priv_root_key = RSA.importKey(priv_root_key_file.read())
-priv_root_key_file.close()
-
-
-#
-# Extract the device public key that we are to sign with the private root key.
-# Dump it in a file to be used by rvi_create_certificate.py
-#
-pub_key_fname = "{}_pub.pem".format(fname_prefix)
-pub_key_file = open(pub_key_fname, 'w')
-pub_key = new_key.publickey()
-pub_key_pem = pub_key.exportKey("PEM") 
-pub_key_file.write(pub_key_pem)
-pub_key_file.close()
-
-print "pub_key.e = ", pub_key.e
-print "pub_key.n = ", pub_key.n
-
-key_obj = { 
-    'keys': [{
-	"kty": "RSA",
-        "alg": "RS256",
-        "use": "sig",
-        "e": long_to_base64(pub_key.e),
-        "n": long_to_base64(pub_key.n)
-    }],
-}
-
-# Generate a JWT signature based on the pub key and the private root key
-signature = jwt.encode(key_obj, priv_root_key.exportKey('PEM'), algorithm='RS256')
-
-
-# Verify that we can use the public root key to verify the key.
-pub_root_key = priv_root_key.publickey().exportKey('PEM')
-
-try: 
-    jwt.decode(signature, pub_root_key)
-except:
-    print "FAILED VERIFICATION!"
-    print "The public portion of the generated device key, signed by the provided private root key,"
-    print "could not be verified using the public root key."
-    os.remove(priv_key_fname)
-    sys.exit(0)
-
-#
-# Create signed public JWT file
-#
-pub_sign_key_fname = "{}_pub_sign.jwt".format(fname_prefix)
-
-pub_sign_key_file = open(pub_sign_key_fname, 'w')
-pub_sign_key_file.write(signature)
-pub_sign_key_file.close()
-
-print "Device private/public key pair stored in:                    ", priv_key_fname
-print "Device public-only key stored in:                            ", pub_key_fname
-print "Device JWT-formatted public key signed by private "
-print "  root key, stored in:                                       ", pub_sign_key_fname
-print "Root key used to sign the device public key read from:       ", priv_root_key_fname
-print
-print "Set rvi node's device_key_pair config parameter to point to: ", priv_root_key_fname
-print "Set rvi node's authorize_jwt config parameter to point to:   ", pub_sign_key_fname
-print
-print "use ./rvi_create_certificate.py ... --device_key={} to include".format(pub_key_fname)
-print "device public key in a certificate."
-
diff --git a/scripts/rvi_ctl.template b/scripts/rvi_ctl.template
new file mode 100644
index 0000000..dc8dd9e
--- /dev/null
+++ b/scripts/rvi_ctl.template
@@ -0,0 +1,141 @@
+#!/bin/sh
+#
+
+#
+# Mozilla Public License, version 2.0.  The full text of the 
+# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+#
+#
+# Setup a correct configuration and launch an RVI release node.
+# If a UUID file has not been created, it will be done at this time.
+# Init.d script to start and stop an RVI system installed
+# through an RPM.
+#
+
+# Assignment of default values done by rvi_install.sh
+echo ${RVI_BINDIR:="__RVI_BINDIR__"} > /dev/null
+echo ${RVI_LOGDIR:="__RVI_LOGDIR__"} > /dev/null
+echo ${ERL:=erl} > /dev/null
+
+
+
+usage() {
+    echo "Usage: $0 -d config_dir [-c config_file] -l log_dir \\" 
+    echo "       start|stop|console|attach|ping"
+    echo
+    echo "  -c config_file  Configuration file to launch rvi node with."
+    echo "                  Mandatory for start and console. Ignored for"
+    echo "                  all other commands."
+    echo
+    echo "  start           Start an rvi node with the given configuration file."
+    echo
+    echo "  stop            Stop an rvi node previously started with 'start'."
+    echo
+    echo "  console         Start an rvi in foreground mode."
+    echo 
+    echo "  attach          Attach to an rvi node previously started with 'start'."
+    echo
+    echo "Environennt variables. Default value in paranthesis::"
+    echo "\$RVI_BINDIR ($RVI_BINDIR)  Location of binary files."
+    echo "\$RVI_LOGDIR ($RVI_LOGDIR)  Location of log files."
+    exit 1
+}
+
+CONFIG_FILE=""
+SNAME=rvi
+COOKIE=rvi_cookie
+while getopts "c:" o; do
+    case "${o}" in
+        c)
+            CONFIG_FILE=${OPTARG}
+            ;;
+        *)
+            usage
+            ;;
+    esac
+done
+
+shift $((${OPTIND}-1))
+CMD=$1
+
+
+if [ "${CMD}" != "start" -a "${CMD}" != "stop" -a  "${CMD}" != "console" -a  "${CMD}" != "ping" ]
+then
+    usage
+fi
+
+RUNDIR=${RVI_RUNDIR:-"/tmp/rvi_${$}"}
+
+export ERL_LIBS=${RVI_BINDIR}:${RVI_BINDIR}/deps:${RVI_BINDIR}/components
+
+#
+# See if we need to process a config file
+#
+if [ ${CMD} = "start" -o ${CMD} = "console" ]
+then
+    if [ -z "${CONFIG_FILE}" ]
+    then
+	echo "Missing -c <config_file> argument."
+	usage
+    fi
+    #
+    # Check if we need to prepend current dir
+    # to relative config file path
+    #
+    if [ $(echo ${CONFIG_FILE} | cut -c 1,1) != "/" ]
+    then
+	CONFIG_FILE=${PWD}/${CONFIG_FILE}
+    fi
+
+    # Check that config file can be read.
+    if [ ! -r "${CONFIG_FILE}" ]
+    then
+	echo "${CONFIG_FILE} cannot be opened for reading."
+	usage
+    fi
+    # 
+    # Generate a config file that will end up as
+    # /tmp/rvi/[cfg]/sys.config
+    #
+    (
+	rm -rf ${RUNDIR}
+	install -d --mode=0755 ${RUNDIR}
+	cd ${RUNDIR}
+	${RVI_BINDIR}/setup_gen rvi ${CONFIG_FILE} rvi
+    )
+
+    # Did we succeed with config generation?
+    if [ "$?" != "0" ]
+    then
+	# Nope
+	echo "Failed to process configuration file."
+	exit "$?"
+    fi
+fi
+
+LAUNCH="${ERL} -boot ${RUNDIR}/rvi/start -sname ${SNAME} -config ${RUNDIR}/rvi/sys -setcookie ${COOKIE}"
+
+case "${CMD}" in
+   start)
+	 install -D -d --mode 0755  ${RVI_LOGDIR}
+	 exec run_erl -daemon ${RUNDIR}/ ${RVI_LOGDIR} "exec ${LAUNCH}"
+	 ;;
+
+   console)
+       exec ${LAUNCH}
+       ;;
+
+   stop)
+       exec ${RVI_BINDIR}/nodetool -sname ${SNAME} -setcookie ${COOKIE} stop
+       ;;
+
+   ping)
+       exec ${RBI_BINDIR}/nodetool -sname ${SNAME} -setcookie ${COOKIE} ping
+       ;;
+
+   attach) 
+       exec to_erl ${RUNDIR}
+       ;;
+
+esac 
+
diff --git a/scripts/rvi_devrun b/scripts/rvi_devrun
new file mode 100755
index 0000000..901b002
--- /dev/null
+++ b/scripts/rvi_devrun
@@ -0,0 +1,99 @@
+#!/bin/sh
+#
+# Copyright (C) 2014, Jaguar Land Rover
+#
+# This program is licensed under the terms and conditions of the
+# Mozilla Public License, version 2.0.  The full text of the 
+# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+#
+
+#
+# Launch an RVI node using the build directories
+# For now this is a simple wrapper around the installer
+
+SELF_DIR=$(dirname $(readlink -f "$0"))
+PRIV_DIR=$(dirname ${SELF_DIR})/priv
+TARGET_DIR=""
+ROOT_CERT="${PRIV_DIR}/certificates/insecure_root_cert.crt"
+DEVICE_CERT="${PRIV_DIR}/certificates/insecure_device_cert.crt"
+DEVICE_KEY="${PRIV_DIR}/keys/insecure_device_key.pem"
+DEVICE_CRED="${PRIV_DIR}/credentials/insecure_credential.jwt"
+
+usage() {
+    cat <<EOF
+Usage:
+$0 [-r root_cert] [-d device_cert] [-c credentials] config_file
+ 
+Run a developer version of RVI
+ 
+-r root_cert    - The certificate to validate received X509 device
+                  certificates and credentials.
+                  Default ${ROOT_CERT}
+ 
+-k device_key   - The PEM file containing the device key pair used
+                  to sign traff
+                  Default ${DEVICE_KEY}
+
+-d device_cert  - Certificate to use when authenticating self toward 
+                  remote nodes.
+                  Default ${DEVICE_CERT}
+
+-c credentials  - Credentials to present to remote nodes. Can be specified
+                  multiple times
+                  Default ${DEVICE_CRED}
+                         
+EOF
+    exit 1
+}
+
+while getopts "r:d:c:k:" o; do
+    case "${o}" in
+	r)
+	    ROOT_CERT=${OPTARG}
+	    ;;
+
+	d)
+	    DEVICE_CERT=${OPTARG}
+	    ;;
+
+	c)
+	    DEVICE_CRED=${OPTARG}
+	    ;;
+
+	k)
+	    DEVICE_KEY=${OPTARG}
+	    ;;
+        *)
+            usage
+            ;;
+    esac
+done
+
+shift $((${OPTIND}-1))
+
+# Check that we have a target dir
+
+if [ "${#}" != "1" ]
+then
+    echo "ERROR: Wrong number of arguments. Only specify config file"
+    usage
+fi
+
+CONFIG_FILE=${1}
+
+./scripts/rvi_install \
+    -k ${DEVICE_KEY} \
+    -r ${ROOT_CERT} \
+    -d ${DEVICE_CERT} \
+    -c ${DEVICE_CRED} \
+    /tmp/rvi_dev/rvi_core > /tmp/dev_install.log
+
+if [ "${?}" != "0" ]
+then
+    echo "ERROR: Devevelop install failed:"
+    cat /tmp/dev_install.log
+    exit 255
+fi
+
+/tmp/rvi_dev/rvi_core/rvi_ctl -c ${CONFIG_FILE} console
+
diff --git a/scripts/rvi_install b/scripts/rvi_install
new file mode 100755
index 0000000..ac128e5
--- /dev/null
+++ b/scripts/rvi_install
@@ -0,0 +1,322 @@
+#!/bin/sh
+#
+# Copyright (C) 2014, Jaguar Land Rover
+#
+# This program is licensed under the terms and conditions of the
+# Mozilla Public License, version 2.0.  The full text of the 
+# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+#
+
+#
+# Setup an RVI release
+#
+#
+
+SELF_DIR=$(dirname $(readlink -f "$0"))
+SETUP_GEN=$SELF_DIR/setup_gen  # Ulf's kitchen sink setup utility
+
+usage() {
+    cat <<EOF
+Usage:
+$0 -r root_cert -d device_cert -c credentials \\
+  [-l log_dir ] [-s prefix_strip] target_dir
+ 
+Install a built RVI system into a target directory
+ 
+NOTE: The last component of 'taget_dir' must be named 'rvi_core'
+       Example: /opt/rvi_core
+ 
+-l log_dir      - Log directory. Default: ${target_dir}/log.
+
+-s prefix_strip - See below. Default: nil.
+
+-r root_cert    - The certificate to validate received X509 device
+                  certificates and credentials.
+ 
+-k device_key   - The PEM file containing the device key pair used
+                  to sign traff
+
+-d device_cert  - Certificate to use when authenticating self toward 
+                  remote nodes.
+
+-c credentials  - Credentials to present to remote nodes. Can be specified
+                  multiple times
+                         
+The created node can be started with: 'target'/rvi_ctl
+The RVI installation will rely on a separate erlang install
+to run.
+
+PREFIX STRIPPING
+  If '-s prefix_strip' is provided, that part of the directories above
+  will be stripped of the given prefix in all internlal references.
+  This is useful in debian and other build systems.
+
+  If, for example, 'target_dir' is './build/root/usr/bin', and
+  'prefix_strip' is './build/root', all internal paths will
+  reference '/usr/bin'.
+ 
+ROOT CERTIFICATE
+  The root certificate is used to validate remote TLS connections and
+  device certificates. It is normally generated once and shared across
+  all RVI nodes.  An initial root certificate, and its corresponding
+  keys can be generated using the following command.
+
+  # Create a root key pair
+  openssl genrsa -out root_key.pem 4096
+
+  # Create a self-signed root certificate using the key above.
+  openssl req -x509 -new -nodes -key root_key.pem \\
+     -days 365 -out root_cert.crt
+
+  The root key pair should be stored securely and not be distributed.
+
+  Provide the generated root_cert.crt file as a '-r' argument to rvi_install.
+
+DEVICE KEY PAIR
+  The device key pair is used to sign outgoing message based traffic, and
+  to create a device certificate signing request (See DEVICE CERTIFICATE)
+
+  Create the device key PEM file using the following command:
+
+  # Create a certificate signing request
+  openssl req -new -key device_key.pem -out device_cert.csr
+
+  Provide the generated device_key.pem file as a '-k' argument to rvi_install.
+
+DEVICE CERTIFICATE
+  The device certificate, signed by the root certificate, is sent over
+  to the remote RVI node to prove that self is an authentic node
+  provisioned by the owner of the root key and certificate.
+
+  A device certificate can be created using the following commands
+
+  # Create the device key pair.
+  openssl genrsa -out device_key.pem 4096
+
+  # Create a certificate signing request
+  openssl req -new -key device_key.pem -out device_cert.csr
+
+  # Sign the signing request and create the device_cert.crt file
+  openssl x509 -req -days 365 -in device_cert.csr \\
+               -CA root_cert.crt -CAkey root_key.pem \\
+               -set_serial 01 -out device_cert.crt
+
+  Provide the generated device_cert.crt file as a '-d' argument to rvi_install.
+
+CREDENTIALS
+  Credentials are provided as JSON Web Tokens (JWT) signed by the root
+  certificate.  The JWT, which has the sender's device certificate
+  embedded into it, proves that the owner of the root key/certificate
+  has approved that the owner of the device certificate has the right
+  to send the credential-specified service calls to the remote node,
+  and receive the credential-specified service calls from the remote
+  node.
+
+  Credentials can be created using the following command (given
+  credential.json as input):
+
+  rvi_create_credential.py --cred_out="credential.json" \\
+                         --jwt_out='credential.jwt' \\
+                         --id="my_device_1234" \\
+                         --issuer="genivi.org" \\
+                         --root_key=root_key.pem \\
+                         --device_cert=device_cert.crt \\
+                         --invoke='genivi.org/' \\
+                         --register='genivi.org/'
+
+  Provide the generated credential.jwt file as a '-c' argument to rvi_install.
+
+EXAMPLE INSTALLATION
+
+  If you want to run an *INSECURE* installation sharing keys
+  certificates, and credentials across all nodes, you can run the
+  following command from the rvi_core root directory to use the
+  provided sample keys, certificates, and credentials:
+
+  $0 -k priv/keys/insecure_device_key.pem \\
+     -r priv/certificates/insecure_root_cert.crt \\
+     -d priv/certificates/insecure_device_cert.crt \\
+     -c priv/credentials/insecure_credential.jwt \\
+     /opt/rvi_core
+
+
+  WARNING: This example installation will provide no protection
+           against unauthenticated nodes, unauthorized calls, or
+           eavesdropping. Do not use in any externally facing 
+           environment.
+
+EOF
+ exit 1 
+}
+
+if [ "${#}" = "0" ] 
+then
+    usage
+fi
+
+TARGET_DIR=""
+LOG_DIR=""
+ROOT_CERT=""
+DEVICE_CERT=""
+DEVICE_KEY=""
+DEVICE_CRED=""
+
+while getopts "r:d:c:k:s:l:" o; do
+    case "${o}" in
+	r)
+	    ROOT_CERT=${OPTARG}
+	    ;;
+
+	d)
+	    DEVICE_CERT=${OPTARG}
+	    ;;
+
+	c)
+	    DEVICE_CRED="${DEVICE_CRED} ${OPTARG}"
+	    ;;
+
+	k)
+	    DEVICE_KEY=${OPTARG}
+	    ;;
+
+        l)
+	    LOG_DIR=${OPTARG}
+	    ;;
+
+        s)
+	    PREFIX_STRIP=${OPTARG}
+            ;;
+
+        *)
+            usage
+            ;;
+    esac
+done
+
+shift $((${OPTIND}-1))
+
+# Check that we have a target dir
+
+if [ "${#}" != "1" ]
+then
+    echo "ERROR: Wrong number of arguments. Only specify target_dir"
+    usage
+fi
+
+TARGET_DIR=${1}
+
+# Make sure that the last element of target dir is rvi_core
+# This is an erlang runtime requirement.
+if [ $(basename ${TARGET_DIR}) != "rvi_core" ]
+then
+    echo "ERROR: Last component of 'target_dir' must be named rvi_core."
+    echo "       Example: $(dirname ${TARGET_DIR})/rvi_core"
+    echo "       Run ${0} with no arguments for usage."
+    exit 255
+fi 
+
+# Check that we can read the root cert
+if [ -z "${ROOT_CERT}" -o ! -r "${ROOT_CERT}" ]
+then
+    echo "ERROR: Cannot read root certificate ${ROOT_CERT}."
+    echo "       Run ${0} with no arguments for usage."
+    exit 255
+fi
+
+# Check that we can read the device key PEM file
+if [ -z "${DEVICE_KEY}" -o ! -r ${DEVICE_KEY} ]
+then
+    echo "ERROR: Cannot read device key ${DEVICE_KEY}."
+    echo "       Run ${0} with no arguments for usage."
+    exit 255
+fi
+
+# Check that we can read the device cert
+if [ -z "${DEVICE_CERT}" -o ! -r ${DEVICE_CERT} ]
+then
+    echo "ERROR: Cannot read device certificate ${DEVICE_CERT}."
+    echo "       Run ${0} with no arguments for usage."
+    exit 255
+fi
+
+# Check that we have at least one device credential
+if [ -z "${DEVICE_CERT}" ]
+then
+    echo "ERROR: No device credential specified"
+    echo "       Run ${0} with no arguments for usage."
+    exit 255
+fi
+
+# Check that we can read each device credential
+for CRED in ${DEVICE_CRED}; do
+
+    if [ ! -r ${CRED} ]
+    then
+	echo "ERROR: Cannot read device certificate ${CRED}."
+	echo "       Run ${0} with no arguments for usage."
+	exit 255
+    fi
+done
+
+#
+# Use default log dir if not specified
+#
+if [ -z "${LOG_DIR}" ]
+then
+    LOG_DIR=${TARGET_DIR}/log
+fi
+
+# Wipe old target dir.
+rm -rf ${TARGET_DIR} > /dev/null 2>&1 
+
+# Create log dirs
+install -m 0755 -d ${TARGET_DIR}
+install -m 0755 -d ${LOG_DIR}
+
+# Copy over the relevant files to the target
+FILE_SET=$(find ebin components deps -name ebin -o -name priv)
+tar cf - ${FILE_SET} | (cd ${TARGET_DIR} ; tar xf - )
+
+# If we have a prefix strip (for build systems not using
+# chroot), apply it to paths.
+if [ -s "${PREFIX_STRIP}" ] 
+then
+    STRIP_TARGET_DIR=$(echo ${TARGET_DIR} | sed "s|^${PREFIX_STRIP}||")
+    STRIP_LOG_DIR=$(echo ${LOG_DIR} | sed "s|^${PREFIX_STRIP}||")
+else
+    STRIP_TARGET_DIR=${TARGET_DIR}
+    STRIP_LOG_DIR=${LOG_DIR}
+fi
+
+# Patch rvi_ctl.template to set its ERL_LIBS path correctly.
+sed -e "s|__RVI_BINDIR__|${STRIP_TARGET_DIR}|g" \
+    -e "s|__RVI_LOGDIR__|${STRIP_LOG_DIR}|g" < scripts/rvi_ctl.template > /tmp/rvi_ctl
+
+# Install all relevant scripts.
+install -m 0755 -d ${TARGET_DIR}/priv/certificates
+install -m 0755 -d ${TARGET_DIR}/priv/keys
+install -m 0755 -d ${TARGET_DIR}/priv/credentials
+install -m 0644 ${ROOT_CERT} ${TARGET_DIR}/priv/certificates/root_cert.crt
+install -m 0644 ${DEVICE_CERT} ${TARGET_DIR}/priv/certificates/device_cert.crt
+install -m 0644 ${DEVICE_KEY} ${TARGET_DIR}/priv/keys/device_key.pem
+install -m 0644 ${DEVICE_CRED} ${TARGET_DIR}/priv/credentials
+install -m 0755 /tmp/rvi_ctl ${TARGET_DIR}
+rm /tmp/rvi_ctl
+install -m 0755 scripts/setup_gen ${TARGET_DIR}
+install -m 0755 rel/files/nodetool ${TARGET_DIR}
+install -m 0755 python/rvi_service.py ${TARGET_DIR}/rvi_service
+install -m 0755 python/rvi_call.py ${TARGET_DIR}/rvi_call
+install -m 0644 python/rvilib.py ${TARGET_DIR}
+install -m 0755 python/rvi_get_services.py ${TARGET_DIR}/rvi_get_services
+install -m 0755 -D priv/config/rvi_common.config ${TARGET_DIR}/priv/config/rvi_common.config
+
+echo "RVI binary files installed under ${TARGET_DIR}"
+echo "RVI will log to ${LOG_DIR}"
+echo
+echo "Start:              ${TARGET_DIR}/rvi_ctl -c <config_file> start"
+echo "Attach started RVI: ${TARGET_DIR}/rvi_ctl attach"
+echo "Stop:               ${TARGET_DIR}/rvi_ctl stop"
+echo "Start console mode: ${TARGET_DIR}/rvi_ctl -c <config_file> console"
+echo
+exit 0
+
diff --git a/scripts/rvi_install.sh b/scripts/rvi_install.sh
deleted file mode 100755
index 7e949a1..0000000
--- a/scripts/rvi_install.sh
+++ /dev/null
@@ -1,88 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2014, Jaguar Land Rover
-#
-# This program is licensed under the terms and conditions of the
-# Mozilla Public License, version 2.0.  The full text of the 
-# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
-#
-
-#
-# Setup an RVI release with a configuration file.
-#
-# This script will setup a directory with with the same name
-# as the release name. The script uses Ulf Wiger's setup application 
-# (github.com/Feuerlabs/setup) to generate the release.
-# 
-# With the -d argument, a developer release will be built with
-# only
-#
-#  Once setup, the RVI node can be started with ./rvi_node <release_na,e?
-#
-#  Please note that the generated release will depend on the built
-#
-#  In order to create a standalone release, use create_rvi_release.sh
-#
-
-SELF_DIR=$(dirname $(readlink -f "$0"))
-SETUP_GEN=$SELF_DIR/setup_gen  # Ulf's kitchen sink setup utility
-
-usage() {
-    echo "Usage: $0 binary_dir"
-    echo 
-    echo "RVI will be installed in 'target_dir'."
-    echo 
-    echo "The created node can be started with: 'target_dir'/rvi.sh"
-    echo "RVI in 'target_dir' will rely on a native erlang to function"
-    exit 1
-}
-
-
-
-shift $((${OPTIND}-1))
-
-if [ "${#}" != "1" ]
-then
-    echo "Target directory not specifiied."
-    usage
-fi
-
-TARGET_DIR=$1
-
-#
-# Prepend abs path if TARGET_DIR is relative
-#
-if [ $(echo ${TARGET_DIR} | cut -c 1,1) != "/" ]
-then
-    TARGET_DIR=${PWD}/${TARGET_DIR}
-fi
-
-
-cd ${SELF_DIR}/..;
-
-rm -rf ${TARGET_DIR} > /dev/null 2>&1 
-
-install --mode=0755 -d ${TARGET_DIR}/rvi_core
-install --mode=0755 -d ${TARGET_DIR}/scripts
-
-FILE_SET=$(find priv ebin components deps -name ebin -o -name priv)
-
-echo "Installing rvi at ${TARGET_DIR}."
-
-tar cf - ${FILE_SET} | (cd ${TARGET_DIR}/rvi_core ; tar xf - )
-install --mode=0755 scripts/rvi.sh ${TARGET_DIR}
-install --mode=0755 scripts/setup_gen ${TARGET_DIR}/scripts
-install --mode=0755 rel/files/nodetool ${TARGET_DIR}/scripts
-install --mode=0755 scripts/rvi_create_root_key.sh ${TARGET_DIR}/scripts
-install --mode=0755 scripts/rvi_create_device_key.sh ${TARGET_DIR}/scripts
-install --mode=0755 scripts/rvi_create_certificate_key.sh ${TARGET_DIR}/scripts
-
-
-echo "RVI installed under ${TARGET_DIR}"
-echo "Start:              ${TARGET_DIR}/rvi.sh -c <config_file> start"
-echo "Attach started RVI: ${TARGET_DIR}/rvi.sh attach"
-echo "Stop:               ${TARGET_DIR}/rvi.sh stop"
-echo "Start console mode: ${TARGET_DIR}/rvi.sh -c <config_file> console"
-
-exit 0
-
diff --git a/scripts/rvi_node.sh b/scripts/rvi_node.sh
deleted file mode 100755
index a7cd201..0000000
--- a/scripts/rvi_node.sh
+++ /dev/null
@@ -1,84 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2014, Jaguar Land Rover
-#
-# This program is licensed under the terms and conditions of the
-# Mozilla Public License, version 2.0.  The full text of the 
-# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
-#
-
-#
-# Launch an RVI node using the build direcotriuies.
-#
-# This script launches the erlang runtime system and executes the RVI
-# code directly from its build directory. Use ./setup_rvi_node without
-# the -d flag to create an installable release that can execute
-# without the use of this script.
-#
-# This script can be executed after a setup_node.sh has been executed to 
-# create the necessary config files and erlang boot scripts.
-#
-alias realpath="python -c 'import os, sys; print os.path.realpath(sys.argv[1])'"
-SELF_DIR=$(dirname $(realpath "$0"))
-
-usage() {
-    echo "Usage: $0 [-d] -n node_name"
-    echo "  -n node_name          Specify the name of the rvi node to launch"
-    echo "  -d                    Daemon mode (using start_erl)"
-    echo "Configuration data is read from the configuration file"
-    echo "provided to the setup_rvi_node.sh script that created the node."
-    exit 1
-}
-
-mode=build
-daemon=0
-while getopts ":n:dbrp:s:" o; do
-    case "${o}" in
-        n)
-            node_name=${OPTARG}
-            ;;
-        d)
-            daemon=1
-            ;;
-        *)
-            usage
-            ;;
-    esac
-done
-
-if [ -z "${node_name}" ] ; then
-    echo "Missing -n flag"
-    usage
-fi
-
-# check man erl for extra arguments
-
-if [ "${mode}" = "build" ]
-then
-    if [ ! -f ${node_name}/sys.config ]
-    then
-	echo "Node ${node_name} not setup. Please run: "
-	echo "$SELF_DIR/setup_rvi_node.sh -n ${node_name} -c <configuration_file>"
-	exit 2
-    fi
-    xboot="-boot ${node_name}/start"
-    xname="-sname ${node_name}"
-    xcfg="-config ${node_name}/sys"
-    CMD="erl ${xboot} ${xname} ${xcfg} -setcookie rvi_core"
-    if [ ${daemon} = 1 ]
-    then
-	PIPE=/tmp/rvi_node/${node_name}
-	LOG=${node_name}/log
-	mkdir -p ${PIPE}
-	mkdir -p ${LOG}
-	echo "starting with run_erl"
-        exec run_erl -daemon ${PIPE} ${LOG} "exec ${CMD}"
-    else
-	exec ${CMD}
-    fi
-
-elif [ "${mode}" = "release" ]
-then
-    echo "Not yet supported."
-    exit 0
-fi
diff --git a/src/rvi_core.app.src b/src/rvi_core.app.src
index 977e79e..93fa67a 100644
--- a/src/rvi_core.app.src
+++ b/src/rvi_core.app.src
@@ -12,7 +12,7 @@
 {application, rvi_core,
  [
   {description, ""},
-  {vsn, "0.4.0"},
+  {vsn, "0.5.0"},
   {registered, []},
   {applications, [
                   kernel,
diff --git a/test/rvi_core_SUITE.erl b/test/rvi_core_SUITE.erl
index bd76d91..c61e8ce 100644
--- a/test/rvi_core_SUITE.erl
+++ b/test/rvi_core_SUITE.erl
@@ -22,6 +22,8 @@
     t_install_tls_sample_node/1,
     t_install_tlsj_backend_node/1,
     t_install_tlsj_sample_node/1,
+    t_install_tls_backend_noverify_node/1,
+    t_install_tls_sample_noverify_node/1,
     t_install_bt_backend_node/1,
     t_install_bt_sample_node/1,
     t_start_basic_backend/1,
@@ -32,6 +34,8 @@
     t_start_tls_sample/1,
     t_start_tlsj_backend/1,
     t_start_tlsj_sample/1,
+    t_start_tls_backend_noverify/1,
+    t_start_tls_sample_noverify/1,
     t_register_lock_service/1,
     t_register_sota_service/1,
     t_call_lock_service/1,
@@ -55,6 +59,7 @@ all() ->
      {group, test_run},
      {group, test_run_tls},
      {group, test_run_tlsj},
+     {group, test_run_tls_noverify},
      {group, test_run_bt}
     ].
 
@@ -74,6 +79,8 @@ groups() ->
        t_install_tls_sample_node,
        t_install_tlsj_backend_node,
        t_install_tlsj_sample_node,
+       t_install_tls_backend_noverify_node,
+       t_install_tls_sample_noverify_node,
        t_install_bt_backend_node,
        t_install_bt_sample_node
       ]},
@@ -114,6 +121,19 @@ groups() ->
        t_remote_call_lock_service,
        t_no_errors
       ]},
+     {test_run_tls_noverify, [],
+      [
+       t_start_tls_backend_noverify,
+       t_start_tls_sample_noverify,
+       t_register_lock_service,
+       t_register_sota_service,
+       t_call_lock_service,
+       t_remote_call_lock_service,
+       t_call_sota_service,
+       t_multicall_sota_service,
+       t_check_rvi_log,
+       t_no_errors
+      ]},
      {test_run_bt, [],
       [
        t_start_bt_backend,
@@ -227,6 +247,13 @@ t_install_tlsj_backend_node(_Config) ->
 t_install_tlsj_sample_node(_Config) ->
     install_sample_node("tlsj_sample", "tlsj_sample.config").
 
+t_install_tls_backend_noverify_node(_Config) ->
+    install_rvi_node("tls_backend_noverify", env(),
+		     [root(), "/priv/test_config/tls_backend_noverify.config"]).
+
+t_install_tls_sample_noverify_node(_Config) ->
+    install_sample_node("tls_sample_noverify", "tls_sample_noverify.config").
+
 t_install_bt_backend_node(_Config) ->
     install_rvi_node("bt_backend", env(),
 		     [root(), "/priv/test_config/bt_backend.config"]).
@@ -271,6 +298,12 @@ t_start_tlsj_backend(_Config) ->
 t_start_tlsj_sample(_Config) ->
     generic_start("tlsj_sample").
 
+t_start_tls_backend_noverify(_Config) ->
+    generic_start("tls_backend_noverify").
+
+t_start_tls_sample_noverify(_Config) ->
+    generic_start("tls_sample_noverify").
+
 t_register_lock_service(_Config) ->
     Pid =
 	spawn_cmd(
@@ -436,6 +469,7 @@ start_json_rpc_server(Port) ->
     Pid.
 
 handle_body(Socket, Request, Body, St) ->
+    ct:log("handle_body(Body = ~p)", [Body]),
     JSON = jsx:decode(Body),
     ct:log("Got JSON Req: ~p", [JSON]),
     case JSON of
diff --git a/ubuntu_template/README.Debian b/ubuntu_template/README.Debian
new file mode 100644
index 0000000..f80c683
--- /dev/null
+++ b/ubuntu_template/README.Debian
@@ -0,0 +1,10 @@
+rvi for Debian
+--------------
+
+Will rely on existing Erlang installation to work.
+
+We will copy out the Erlang VM BEAM files to /opt/rvi and the configuration files to /etc/opt/rvi
+
+/opt/rvi/rvi.sh is the main control program.
+
+ -- Magnus Feuer <mfeuer@jaguarlandrover.com>  Fri, 27 Nov 2015 15:34:39 -0800
diff --git a/ubuntu_template/README.source b/ubuntu_template/README.source
new file mode 100644
index 0000000..9e3c927
--- /dev/null
+++ b/ubuntu_template/README.source
@@ -0,0 +1,6 @@
+rvi for Debian
+--------------
+
+
+ -- Magnus Feuer <mfeuer@jaguarlandrover.com>  Fri, 27 Nov 2015 15:34:39 -0800
+
diff --git a/ubuntu_template/changelog b/ubuntu_template/changelog
new file mode 100644
index 0000000..62e7b16
--- /dev/null
+++ b/ubuntu_template/changelog
@@ -0,0 +1,5 @@
+rvi (0.5.0-1ubuntu1) trusty; urgency=low
+
+  * Initial release
+
+ -- Magnus Feuer <mfeuer@jaguarlandrover.com>  Fri, 27 Nov 2015 15:34:39 -0800
diff --git a/ubuntu_template/compat b/ubuntu_template/compat
new file mode 100644
index 0000000..ec63514
--- /dev/null
+++ b/ubuntu_template/compat
@@ -0,0 +1 @@
+9
diff --git a/ubuntu_template/control b/ubuntu_template/control
new file mode 100644
index 0000000..9465e15
--- /dev/null
+++ b/ubuntu_template/control
@@ -0,0 +1,13 @@
+Source: rvi
+Section: net
+Priority: optional
+Maintainer: Magnus Feuer <mfeuer@jaguarlandrover.com>
+Build-Depends: debhelper (>= 9), libbluetooth-dev, esl-erlang (>= 1:18.2)
+Standards-Version: 3.9.5
+Homepage: https://github.com/PDXostc/rvi_core
+
+Package: rvi
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends},bluez, esl-erlang (>= 1:18.2), python-jsonrpclib (>= 0.1.3-1build1), python (>= 2.7.5-5ubuntu3)
+Description: Remote Vehicle Interaction
+ GENIVI Remote Vehicle Interaction Core
diff --git a/ubuntu_template/copyright b/ubuntu_template/copyright
new file mode 100644
index 0000000..89597cf
--- /dev/null
+++ b/ubuntu_template/copyright
@@ -0,0 +1,11 @@
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: rvi
+Source: http://github.com/PDXostc/rvi_core
+
+Files: *
+Copyright:  Copyright 2014,2015,2016 Jaguar Land Rover
+License: MPL-2.0
+ This program is licensed under the terms and conditions of the
+ Mozilla Public License, version 2.0.  The full text of the 
+ Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+
diff --git a/ubuntu_template/docs b/ubuntu_template/docs
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/ubuntu_template/docs
diff --git a/ubuntu_template/rules b/ubuntu_template/rules
new file mode 100755
index 0000000..b6b8c0a
--- /dev/null
+++ b/ubuntu_template/rules
@@ -0,0 +1,21 @@
+#!/usr/bin/make -f
+# -*- makefile --*
+
+# Uncomment this to turn on verbose mode.
+export DH_VERBOSE=1
+
+%:
+	dh $@
+
+override_dh_auto_install:
+	 ./scripts/rvi_install \
+	 	-s ./debian/rvi \
+		-k priv/keys/insecure_device_key.pem \
+		-r priv/certificates/insecure_root_cert.crt \
+		-d priv/certificates/insecure_device_cert.crt \
+		-c priv/credentials/insecure_credential.jwt \
+		-l ./debian/rvi/var/log/rvi ./debian/rvi/usr/lib/rvi_core
+# Copy out rvi_ctl to /usr/bin
+	install -D -m 0755 ./debian/rvi/usr/lib/rvi_core/rvi_ctl ./debian/rvi/usr/bin/rvi_ctl
+# Install default config
+	install -D -m 0644 ./priv/config/rvi_ubuntu.config ./debian/rvi/etc/rvi/rvi.config
diff --git a/ubuntu_template/rvi.init b/ubuntu_template/rvi.init
new file mode 100755
index 0000000..9cd4e59
--- /dev/null
+++ b/ubuntu_template/rvi.init
@@ -0,0 +1,70 @@
+#!/bin/sh
+#
+# Copyright (C) 2014, Jaguar Land Rover
+#
+# This program is licensed under the terms and conditions of the
+# Mozilla Public License, version 2.0.  The full text of the 
+# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+#
+#
+# Init.d script to start and stop an RVI system installed
+# through an RPM.
+#
+### BEGIN INIT INFO
+# Provides:          rvi
+# Required-Start:    $network $syslog $remote_fs
+# Required-Stop:     $network $syslog $remote_fs
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: Start/Stop RVI node at boot time
+# Description:       Manage Remote Vehicle Interaction Node run state.
+### END INIT INFO
+
+export PATH="/bin/:/usr/bin:/sbin:/usr/sbin"
+export HOME=/usr/lib/rvi_core
+. /lib/lsb/init-functions
+
+set -e 
+
+case "$1" in
+  start)
+        log_daemon_msg "Starting Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl -c /etc/rvi/rvi.config start; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+  stop)
+        log_daemon_msg "Stopping Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl stop; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+
+  restart)
+        log_daemon_msg "Restarting Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl restart; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+
+  force-reload)
+        log_daemon_msg "Restarting Remote Vehicle Interaction Node..." "rvi"
+        if /usr/bin/rvi_ctl restart; then
+            log_end_msg 0
+        else
+            log_end_msg 1
+        fi
+        ;;
+  *)
+	log_action_msg "Usage: /etc/init.d/rvi {start|stop|restart}"
+	exit 1
+esac
+
+exit 0
+
diff --git a/ubuntu_template/rvi.lintian-overrides b/ubuntu_template/rvi.lintian-overrides
new file mode 100644
index 0000000..c307106
--- /dev/null
+++ b/ubuntu_template/rvi.lintian-overrides
@@ -0,0 +1,3 @@
+executable-not-elf-or-script
+missing-dep-for-interpreter
+binary-without-manpage
\ No newline at end of file
diff --git a/ubuntu_template/rvi.postinst b/ubuntu_template/rvi.postinst
new file mode 100644
index 0000000..f6d5de5
--- /dev/null
+++ b/ubuntu_template/rvi.postinst
@@ -0,0 +1,50 @@
+#!/bin/sh
+# postinst script for rvi
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#        * <postinst> `configure' <most-recently-configured-version>
+#        * <old-postinst> `abort-upgrade' <new version>
+#        * <conflictor's-postinst> `abort-remove' `in-favour' <package>
+#          <new-version>
+#        * <postinst> `abort-remove'
+#        * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
+#          <failed-install-package> <version> `removing'
+#          <conflicting-package> <version>
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+# source debconf library
+. /usr/share/debconf/confmodule
+
+case "$1" in
+
+  configure)
+    # Set up our config for apache
+    cat /proc/sys/kernel/random/uuid > /etc/rvi/device_id
+    echo "RVI Device ID set to $(cat /etc/rvi/device_id) in /etc/rvi/device_id"
+    update-rc.d rvi defaults
+  ;;
+
+  abort-upgrade|abort-remove|abort-deconfigure)
+    exit 0
+  ;;
+
+  *)
+    echo "postinst called with unknown argument \`$1'" >&2
+    exit 1
+  ;;
+
+esac
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+db_stop
+
+exit 0
diff --git a/ubuntu_template/rvi.postrm b/ubuntu_template/rvi.postrm
new file mode 100644
index 0000000..0ded6f8
--- /dev/null
+++ b/ubuntu_template/rvi.postrm
@@ -0,0 +1,41 @@
+#!/bin/sh
+# postrm script for rvi
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#        * <postinst> `configure' <most-recently-configured-version>
+#        * <old-postinst> `abort-upgrade' <new version>
+#        * <conflictor's-postinst> `abort-remove' `in-favour' <package>
+#          <new-version>
+#        * <postinst> `abort-remove'
+#        * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
+#          <failed-install-package> <version> `removing'
+#          <conflicting-package> <version>
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+# source debconf library
+. /usr/share/debconf/confmodule
+
+case "$1" in
+
+  remove|purge|upgrde|disappear)
+    rm -f /etc/init.d/rvi
+    update-rc.d rvi remove
+  ;;
+
+  *)
+    exit 0
+  ;;
+
+
+esac
+
+#DEBHELPER#
+
+db_stop
+
+exit 0
diff --git a/ubuntu_template/source/format b/ubuntu_template/source/format
new file mode 100644
index 0000000..163aaf8
--- /dev/null
+++ b/ubuntu_template/source/format
@@ -0,0 +1 @@
+3.0 (quilt)
diff --git a/ubuntu_template/source/lintian-overrides b/ubuntu_template/source/lintian-overrides
new file mode 100644
index 0000000..463abe9
--- /dev/null
+++ b/ubuntu_template/source/lintian-overrides
@@ -0,0 +1 @@
+source-is-missing
diff --git a/yocto_template/rvi.init b/yocto_template/rvi.init
new file mode 100755
index 0000000..069d78a
--- /dev/null
+++ b/yocto_template/rvi.init
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# Copyright (C) 2014, Jaguar Land Rover
+#
+# This program is licensed under the terms and conditions of the
+# Mozilla Public License, version 2.0.  The full text of the 
+# Mozilla Public License is at https://www.mozilla.org/MPL/2.0/
+#
+#
+# Init.d script to start and stop an RVI system installed
+# through an RPM.
+#
+### BEGIN INIT INFO
+# Provides:          rvi
+# Default-Start:     3 5
+# Default-Stop:      0 1 2 6
+# Short-Description: RVI Framework
+### END INIT INFO
+
+
+export PATH="/bin/:/usr/bin:/sbin:/usr/sbin"
+. /etc/init.d/functions
+
+set -e 
+
+DAEMON_PATH="/opt/rvi_core"
+DAEMON_NAME="rvi"
+
+case "$1" in
+  start)
+        echo -n "Starting $DAEMON_NAME: "
+        $DAEMON_PATH/rvi_ctl -c /etc/opt/rvi/rvi.config start
+        RETVAL=$?
+        if [ $RETVAL -eq 0 ] ; then
+            echo "OK"
+        else
+            echo "FAIL"
+        fi
+        ;;
+
+  stop)
+        echo -n "Stopping $DAEMON_NAME: "
+        $DAEMON_PATH/rvi_ctl stop
+        RETVAL=$?
+        if [ $RETVAL -eq 0 ] ; then
+            echo "OK"
+        else
+            echo "FAIL"
+        fi
+        ;;
+
+  restart)
+        echo -n "Restarting $DAEMON_NAME: " 
+        $DAEMON_PATH/rvi_ctl restart
+        RETVAL=$?
+        if [ $RETVAL -eq 0 ] ; then
+            echo "OK"
+        else
+            echo "FAIL"
+        fi
+        ;;
+
+    status)
+        status $DAEMON_NAME
+        RETVAL=$?
+        ;;
+
+  *)
+	echo "usage: $0 { start | stop | status | restart | status }"
+	;;
+esac
+
+exit $RETVAL
diff --git a/yocto_template/rvi.service b/yocto_template/rvi.service
new file mode 100644
index 0000000..7e38b78
--- /dev/null
+++ b/yocto_template/rvi.service
@@ -0,0 +1,17 @@
+# systemd(8) setup usde by Yocto Project
+[Unit]
+Description=Remote Vehicle Interaction Service
+Wants=network-online.target
+
+[Service]
+Environment="HOME=/opt/rvi_core"
+Type=forking
+StandardOutput=journal
+StandardError=journal
+ExecStart=/opt/rvi_core/rvi_ctl -c /etc/opt/rvi/rvi.config start
+ExecStop=/opt/rvi_core/rvi_ctl stop
+GuessMainPID=yes
+RemainAfterExit=yes
+
+[Install]
+WantedBy=graphical.target multi-user.target