Misc fixes (secure-device-onboard#56)

Few more fixes related to rendering and attributions.

Signed-off-by: Behera, Tushar Ranjan <[email protected]>

Author: trbehera

docs/installation.md

@@ -6,13 +6,13 @@ This document can be used as a quick start guide to setup the development enviro
 
 | Component | Recommended |
 |------- |------|
-| Operating System | Ubuntu 18.04 / Windows 10 |
-| Docker Engine | 18.09 |
-| Docker-compose | 1.21.2 |
-| maven | 3.5.4 |
+| Operating System | Ubuntu\* 18.04 / Windows\* 10 |
+| Docker* Engine | 18.09 |
+| Docker* Compose | 1.21.2 |
+| Maven* | 3.5.4 |
 
 ## Docker* Installation
-1 . Removing the older versions of Docker. If these are installed, uninstall them:
+1 . Removing the older versions of Docker*. If these are installed, uninstall them:
 ```
 sudo apt-get remove docker docker-engine docker.io containerd runc
 ```
@@ -30,27 +30,27 @@ sudo apt-get remove docker docker-engine docker.io containerd runc
 !!! NOTE
     If you are working behind a proxy, ensure to set proper proxy variables.
 
-3 . Add Docker’s official GPG key:
+3 . Add official GPG key for Docker*:
 ```
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
 ```
 4 . Use the following command to set up the **stable** repository.
 ```
 sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable"
 ```
-5 . Update the `apt` package index and install the docker engine 18.09
+5 . Update the `apt` package index and install the Docker* Engine 18.09
 ```
 sudo apt-get update
 sudo apt-get install docker-ce=5:18.09.9~3-0~ubuntu-bionic docker-ce-cli=5:18.09.9~3-0~ubuntu-bionic containerd.io
 ```
-6 . Verify that Docker Engine is installed correctly by running the `hello-world` image.
+6 . Verify that Docker* Engine is installed correctly by running the `hello-world` image.
 ```
 sudo docker run hello-world
 ```
 
 ### Running the Docker* behind a proxy
 
-To run the docker system behind a proxy server, the configuration is done by the following steps:
+To run the Docker* system behind a proxy server, the configuration is done by the following steps:
 
 1 . Directory `docker.service.d` is to be created in systemd directory as shown below.
 ```
@@ -83,7 +83,7 @@ Environment="HTTPS_PROXY=<Proxy IP/URL:Port>"
 }
 ```
 
-5 . After configuring the above, the docker needs to be restarted.
+5 . After configuring the above, the Docker* service needs to be restarted.
 ```
 sudo systemctl daemon-reload
 sudo systemctl restart docker
@@ -94,10 +94,10 @@ sudo systemctl restart docker
 sudo systemctl show --property Environment docker
 ```
 
-## Docker-compose Installation
-To install a specific version of docker-compose (for example **_1.21.2_**) follow these steps:
+## Docker* Compose Installation
+To install a specific version of Docker\* Compose (for example **_1.21.2_**) follow these steps:
 
-1 . Download the specific version **(1.21.2)** of docker-compose.
+1 . Download the specific version **(1.21.2)** of Docker* Compose.
 ```
 sudo curl -L https://github.com/docker/compose/releases/download/1.21.2/docker-compose-`uname -s`-`uname -m` -o /usr/bin/docker-compose
 ```

docs/iot-platform-sdk/development-guide.md

@@ -7,9 +7,9 @@ The implementation of these REST contracts in an OCS can be done in any programm
 !!! Note
     The implementation of the pre-defined contracts can be backed by non-REST interfaces as well. However, this would invlove updates to both OPS and To0Scheduler to facilitate communication with the newly defined interface at OCS. Such a change would involve, but is not limited to, updates to existing class `RestClient.java` at both OPS and To0Scheduler.
 
-## Rest Contracts between OCS (server) and OPS/To0Scheduler (client)
+## Rest Contracts between OCS(Server) and OPS/To0Scheduler(Client)
 
-Following are the pre-defined REST API specifications for all the resource paths that must be implemented and exposed by an OCS implementation. Both, OPS and To0Scheduler make requests to the OCS implementation, as clients, using this format.
+The following are the pre-defined REST API specifications for all the resource paths that must be implemented and exposed by an OCS implementation. Both, OPS and To0Scheduler make requests to the OCS implementation, as clients, using this format.
 
 | Operation                               | Description                                                  | Path/Query Parameters                    | Request Body  | Response Body |
 | ---------------------------------------:|:------------------------------------------------------------:|:----------------------------------------:|:-------------:|--------------:|
@@ -35,7 +35,7 @@ Following are the pre-defined REST API specifications for all the resource paths
 | `DELETE` /v1/devices/{deviceId}/sessioninfo  | Delete the TO2 session info corresponding to the `deviceId`.   | Path: `deviceId`: Device identifier |               |               |
 | `GET` /devices/{deviceId}/resale  | Get the `resale` flag indicating owner's support for resale of the corresponding `deviceId`.   | Path: `deviceId`: Device identifier |               |    Boolean    |
 
-## Rest Contracts between To0Scheduler (server) and OCS (client)
+## Rest Contracts between To0Scheduler(Server) and OCS(Client)
 
 An OCS implementation must, also, act as a client to trigger TO0 for set of devices, by making the following request to To0Scheduler. To0Scheduler accepts the request from OCS to initiate TO0 for the list of devices.
 
@@ -46,7 +46,7 @@ An OCS implementation must, also, act as a client to trigger TO0 for set of devi
 
 ## Message Types
 
-Following is a list of message types that are sent in the message body of each request/response. Each message type follows the standard JSON* schema. Statements after '#' inside the JavaScript Object Notation (JSON), represents the purpose of the field.
+Following is a list of message types that are sent in the message body of each request/response. Each message type follows the standard JSON\* schema. Statements after '#' inside the JavaScript* Object Notation (JSON), represents the purpose of the field.
 
 ### DeviceState
 This JSON* structure represents the state information of the device.
@@ -243,4 +243,4 @@ This JSON* structure represents the request message that is sent from the OCS to
            ],
   "waitSeconds": String        # Suggested number of seconds for which TO0 will be valid
 }
-```
+```

docs/iot-platform-sdk/introduction.md

@@ -117,4 +117,4 @@ Limitations of This Release
 
 - The number of concurrent TO0 sessions are limited by a configuration property. TO0 requests for any numbers of devices may be dropped if this limit is reached.
 
-- The keystore and truststore passwords are present in the configuration files as plain text. Special care must be taken to secure the configuration files.
+- The keystore and truststore passwords are present in the configuration files as plain text. Special care must be taken to secure the configuration files.