fix typing and grammar errors

13 files changed, 25 insertions, 25 deletions

diff --git a/docs/proposals/EdgeSite.md b/docs/proposals/EdgeSite.md
index b364154b8..32fbbf08d 100644
--- a/docs/proposals/EdgeSite.md
+++ b/docs/proposals/EdgeSite.md
@@ -17,15 +17,15 @@ admins/users can leverage the local control plane to implement management functi
 This design doc is to enable customers deploy and run lightweight clusters at edge.
 
 ## Motivation
-There are scenarios user need to run a standalone Kubernetes cluster at edge to get full control and improve the offline scheduling capability. There are two scenarios user need to do that:
+There are scenarios users need to run a standalone Kubernetes cluster at edge to get full control and improve the offline scheduling capability. There are two scenarios users need to do that:
 
 * The edge cluster is in CDN instead of the user's site
 
-  The CDN sites usually be large around the world and the network connectivity and quality cannot be guaranteed. Another factor is that the application deployed in CDN edge do not need to interact with center usually. For those deploy edge cluster in CDN resources, they need to make sure the cluster is workable without the connection with central cloud not only for the deployed applications but also the schedule capabilities. So that the CDN edge is manageable regardless the connection to one center.
+  The CDN sites usually are large around the world and the network connectivity and quality cannot be guaranteed. Another factor is that the application deployed in CDN edge do not need to interact with center usually. For those deploy edge cluster in CDN resources, they need to make sure the cluster is workable without the connection with central cloud not only for the deployed applications but also the schedule capabilities. So that the CDN edge is manageable regardless the connection to one center.
 
 * User need to deploy an edge environment with limited resources and offline running for most of the time
 
-  In some IOT scenarios, user need to deploy a full control edge environment and running offline.
+  In some IOT scenarios, users need to deploy a full control edge environment and running offline.
 
 For these use cases, a standalone, full controlled, light weight Edge cluster is required.
 By integrating KubeEdge and standard Kubernetes, this proposal enables customers to run an efficient kubernetes cluster for Edge/IOT computing. User can also leverage other smaller Kubernetes implementation such as K3S to make the footprint even smaller.
diff --git a/docs/proposals/cloudcore-ha-design.md b/docs/proposals/cloudcore-ha-design.md
index c7ef02a84..0f2728411 100644
--- a/docs/proposals/cloudcore-ha-design.md
+++ b/docs/proposals/cloudcore-ha-design.md
@@ -55,7 +55,7 @@ At present, CloudCore is essentially an edge-resource distribution center, which
 
 - DeviceController
 
-  Currently only `device` need to be sent to edge-node by DeviceController. The device-related event are all asigned to edge-nodes, and `device.Spec` is recoreding the information of dest-node. So DeviceController do not need a "LocationCache".
+  Currently only `device` need to be sent to edge-node by DeviceController. The device-related event are all assigned to edge-nodes, and `device.Spec` is recoreding the information of dest-node. So DeviceController do not need a "LocationCache".
 
 - SyncController
 
@@ -67,7 +67,7 @@ At present, CloudCore is essentially an edge-resource distribution center, which
   1. LocationCache
   2. sync-CRD in etcd
 
-  For the former, CloudCore will triger the initialization of LocationCache when restarts; For the latter, CloudCore crash does not affect information in etcd. Messages left out during crash will be re-sync when SyncController reruns.
+  For the former, CloudCore will trigger the initialization of LocationCache when restarts; For the latter, CloudCore crash does not affect information in etcd. Messages left out during crash will be re-sync when SyncController reruns.
 
 ### HA in hot standby mode
 #### The lifecycle of CloudCore
diff --git a/docs/proposals/configuration.md b/docs/proposals/configuration.md
index 71b21364d..9faf61289 100644
--- a/docs/proposals/configuration.md
+++ b/docs/proposals/configuration.md
@@ -82,7 +82,7 @@ We recommend referring to the kubernetes component config api design to redesign
 
 * **Forward compatibility**
 
-	For configuration file, support addition/deprecattion of some fields, **Modify field not allowed**.
+	For configuration file, support addition/depreciation of some fields, **Modify field not allowed**.
 	Configuration need a version field.
 
 
diff --git a/docs/proposals/cri.md b/docs/proposals/cri.md
index d11d86381..b20a38a17 100644
--- a/docs/proposals/cri.md
+++ b/docs/proposals/cri.md
@@ -94,7 +94,7 @@ type Config struct {
  ```
 ### Data structure modifications
 
-The edged data strcuture needs to include the remote runtime and runtime name. Also need to add os interface, pod cache and container life cycle manager parameters required for initializing and executing remote runtime.
+The edged data structure needs to include the remote runtime and runtime name. Also need to add os interface, pod cache and container life cycle manager parameters required for initializing and executing remote runtime.
 
 ```go
 //Define edged
@@ -201,7 +201,7 @@ func (e *edged) Start(c *context.Context) {
 
 ### Runtime dependent functional modifications
 
-The following functionalaties which are based on the docker runtime need to be modified to handle the CRI runtimes as well
+The following functionalities which are based on the docker runtime need to be modified to handle the CRI runtimes as well
 
 ```go
 func (e *edged) initializeModules() error {
diff --git a/docs/proposals/csi.md b/docs/proposals/csi.md
index 283a440cc..a2ee2b539 100644
--- a/docs/proposals/csi.md
+++ b/docs/proposals/csi.md
@@ -614,7 +614,7 @@ KubeEdge 1.3
 #### Graduation Criteria
 
 * Failure Recovery Mechanism for High Availability.
-* The User Guide is clear and easy for the users to use in the producation environment.
+* The User Guide is clear and easy for the users to use in the production environment.
 
 #### Release Plan
 
diff --git a/docs/proposals/device-crd.md b/docs/proposals/device-crd.md
index b17ea9a48..c746cab53 100644
--- a/docs/proposals/device-crd.md
+++ b/docs/proposals/device-crd.md
@@ -740,7 +740,7 @@ The following factors need to be evaluated in order to analyze issues with scale
 - The detailed design of device controller watching against cloud and edge and the tree structure of device data stored at cloud and edge.
   - A detailed design for the device controller is provided in earlier section. The device model and the device instance would be stored in etcd in the cloud. The device twin updates are stored at the edge. The device property and visitors , protocol config are stored in config-maps and consumed by mappers.
 - How are we going to use the device data at cloud ? This can help evaluate item 1
-  - This is desribed in the device controller design.
+  - This is described in the device controller design.
 - Currently, we have only one config map per node which stores all the device instances, device models, protocols and visitors for all the devices connected to the edge node. Mappers running on an edge node managing different devices now need to access one global configmap in order to extract information about the device properties and visitors. What should be the best way to partition a monolithic config map into smaller config maps ? Should the partitioning be based on the protocol type or based on device model ?
 
 ## Device Lifecycle Management
@@ -748,7 +748,7 @@ IoT device lifecycle management comprises of several steps listed below
 - Device onboarding / provisioning
   - The device needs to be registered (via authorization or admission control mechanism). This is currently not in scope of this design.
 - Device configuration
-  - The device needs to be reconfigured many a times during it's lifecycle. No new capabilities are added.
+  - The device needs to be reconfigured many times during its lifecycle. No new capabilities are added.
   The device CRD has device twins which contain desired values for control properties. By changing the desired value of a control property , we can re-configure the device behaviour.
 - Device Updates
   - Firmware updates or some bug fixes need to be applied to the device. This can be a scheduled or ad-hoc update.
diff --git a/docs/proposals/device-management-enhance.md b/docs/proposals/device-management-enhance.md
index d57e18c59..df9e8d3f2 100644
--- a/docs/proposals/device-management-enhance.md
+++ b/docs/proposals/device-management-enhance.md
@@ -56,7 +56,7 @@ We propose below modifications on current design.
 * Deal various industrial protocols
   * Currently, only Modbus, OPC-UA and bluetooth are supported by KubeEdge. However there are thousands of industrial protocols. It is impossible to define all these protocols in KubeEdge. If users want to use these un-predefined protocols, we should provide a way to support.
 * Customized provided protocol
-  * If user want to add some special control value, such as bulk related collection, in provided protocol like Modbus, he can use the customized K-V features.
+  * If users want to add some special control value, such as bulk related collection, in provided protocol like Modbus, he can use the customized K-V features.
 
 ## Design Details
 
diff --git a/docs/proposals/edgemesh-design.md b/docs/proposals/edgemesh-design.md
index ebebb2000..d1ec431d5 100644
--- a/docs/proposals/edgemesh-design.md
+++ b/docs/proposals/edgemesh-design.md
@@ -20,12 +20,12 @@ Developers can define services on top of the deployments deployed on the cloud o
 `http://{service_name}/resources`
 
 ## Motivation
-The cloud native and microservice architecture is becoming more and more popular and the edge node is becoming more and more powerful. The user want to decompose their application into multiple microservices. Some of those microservices need to be deployed in edge node to get close to the data generated by devices. By simplify the development, the user need to use the same mechanism to do the service discovery and communication with what they are doing on cloud.
+The cloud native and microservice architecture is becoming more and more popular and the edge node is becoming more and more powerful. The users want to decompose their application into multiple microservices. Some of those microservices need to be deployed in edge node to get close to the data generated by devices. By simplifying the development, the users need to use the same mechanism to do the service discovery and communication with what they are doing on cloud.
 
 ## Constraints and Assumptions
 1. No DNS services available for edge.
 2. The identification and authentication should be handled by microservices.
-3. When service communication between edge to edge, they may work offline. With the purpose to deliver a "expected result" to the user system, the service definition should be push down to the edge right after the definition operation. That is to say, the istio model may not be suitable for edge, in istio model, the service definition is pull from K8S master when the service is invoked.
+3. When service communication between edge to edge, they may work offline. With the purpose to deliver a "expected result" to the user system, the service definition should be pushed down to the edge right after the definition operation. That is to say, the istio model may not be suitable for edge, in istio model, the service definition is pulled from K8S master when the service is invoked.
 4. Only support HTTP communication in the first step
 5. All edge nodes are in the same sub-network and they have the network reachability.
 
diff --git a/docs/proposals/keadm-scope.md b/docs/proposals/keadm-scope.md
index 0a19e841b..551fd156a 100644
--- a/docs/proposals/keadm-scope.md
+++ b/docs/proposals/keadm-scope.md
@@ -238,7 +238,7 @@ Flags:
 
     1. Check version of OS and install subsequently the required pre-requisites using supported steps. Currently we will support **ONLY** (Ubuntu & CentOS)
     2. Check and install all the pre-requisites before executing edge-controller, which are
-        * Docker (currently 18.06.0ce3-0~ubuntu) and check is service is up.
+        * Docker (currently 18.06.0ce3-0~ubuntu) and check if service is up.
         * mosquitto (latest available in OS repos) and check if running.
     3. This command will take `--certPath` (string type) as mandatory option which shall be the certificates path; wherein the certs were transferred from cloud node and uncompressed. It will modify `$GOPATH/src/github.com/kubeedge/kubeedge/edge/conf/edge.yaml` file against `edgehub.websocket.certfile` and `edgehub.websocket.keyfile` fields.
     4. Create `$GOPATH/src/github.com/kubeedge/kubeedge/build/node.json` and apply it using `curl` command to api-server
diff --git a/docs/proposals/mapper-design.md b/docs/proposals/mapper-design.md
index 501a5f1c5..86f0e6f7a 100644
--- a/docs/proposals/mapper-design.md
+++ b/docs/proposals/mapper-design.md
@@ -23,7 +23,7 @@ last-updated: 2019-02-24
 * [Proposal](#proposal)
 
 ## Introduction
-Mapper is an application that is used to connect and and control devices. Following are the responsibilities of mapper:
+Mapper is an application that is used to connect and control devices. Following are the responsibilities of mapper:
 1) Scan and connect to the device.
 2) Report the actual state of twin-attributes of device.
 3) Map the expected state of device-twin to actual state of device-twin.
@@ -117,4 +117,4 @@ This can be an optional component as not all devices support health-checking. In
 
 **6) Controller**: Controller should expose API's for CRUD operations for managing Actions, Schedules, Watchers, Data-Converters, Health-Checkers.
 
-**7) Driver Interface**: Driver Interface is responsible for talking to the the actual device driver while performing an Action. Device drivers can be protocol specific or device specific depending on the type of the device. A corresponding interface should be present in the mapper to talk to the actual driver.
+**7) Driver Interface**: Driver Interface is responsible for talking to the actual device driver while performing an Action. Device drivers can be protocol specific or device specific depending on the type of the device. A corresponding interface should be present in the mapper to talk to the actual driver.
diff --git a/docs/proposals/quic-design.md b/docs/proposals/quic-design.md
index c461dbe35..75a7a8c28 100644
--- a/docs/proposals/quic-design.md
+++ b/docs/proposals/quic-design.md
@@ -20,7 +20,7 @@ Key features of QUIC:
 2. Improved congestion control
 3. [Multiplexing without head of line blocking](https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic?pli=1)
 4. Forward error correction
-5. Connection migiation
+5. Connection migration
 
 <img src="../images/proposals/quic-tcp-udp.png">
 <img src="../images/proposals/quic-connection.png">
diff --git a/docs/proposals/reliable-message-delivery.md b/docs/proposals/reliable-message-delivery.md
index e28a1f75b..c092e1877 100644
--- a/docs/proposals/reliable-message-delivery.md
+++ b/docs/proposals/reliable-message-delivery.md
@@ -45,7 +45,7 @@ returned from edge nodes to ensure the message delivery is in a reliable fashion
 - If cloudcore being restarted or offline for a while, whenever the cloudcore is back online,
 send the latest event to the edge node (if there is any update to be sent).
 - If edgenode being restarted or offline for a while, whenever the node is back online,
-cloudcore will sent the latest event to make it up to date.
+cloudcore will send the latest event to make it up to date.
 
 ## Design Details
 
@@ -89,9 +89,9 @@ to corresponding NodeMessageQueue according to the node name in message.
 then return an ACK message to the cloud.
 
 - If cloudhub does not receive an ACK message within the interval, it will keep resending the message 5 times.
-If all 5 retries fail, cloudhub will discard the event. SyncController will handling these failed events.
+If all 5 retries fail, cloudhub will discard the event. SyncController will handle these failed events.
 
-- Even if the edge node receives the message, the returned ACK message may lost during transmission.
+- Even if the edge node receives the message, the returned ACK message may be lost during transmission.
  In this case, cloudhub will send the message again and the edge can handle the duplicate message.
 
 ### SyncController
@@ -222,7 +222,7 @@ type ObjectSyncStatus struct {
 
 - When cloudcore restarts or starts normally, it will check the resourceVersion to avoid sending old messages.
 
-- During cloudcore restart, if some objects are deleted, the delete event may lost at this time.
+- During cloudcore restart, if some objects are deleted, the delete event may be lost at this time.
 The SyncController will handle this situation. The object GC mechanism is needed here to ensure the deletion:
 compare whether the objects stored in CRD exist in K8s. If not, then SyncController will generate & send a delete event
 to the edge and delete the object in CRD when ACK received.
diff --git a/docs/proposals/web-hook.md b/docs/proposals/web-hook.md
index e4a378fe4..86adf0be1 100644
--- a/docs/proposals/web-hook.md
+++ b/docs/proposals/web-hook.md
@@ -13,7 +13,7 @@ last-updated: 2019-09-11
 ---
 
 # Motivation
-As the evolving of the project, it is foreseeable more API and resouce will be added in the project. kubeedge so far lack of effective way of pre-processing for the object configuration, for example, whether the pod that is going to be created contains the unwanted label, should the specific configmap be protected from deletion etc.
+As the evolving of the project, it is foreseeable more API and resource will be added in the project. kubeedge so far lack of effective way of pre-processing for the object configuration, for example, whether the pod that is going to be created contains the unwanted label, should the specific configmap be protected from deletion etc.
 
 There is a concrete example on the github [issue 845](https://github.com/kubeedge/kubeedge/issues/845), the issue there cannot be addressed by [CRD validation](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#validation), so we need to explore other approach to achieve that purpose.
 
@@ -28,14 +28,14 @@ There is a concrete example on the github [issue 845](https://github.com/kubeedg
 * Start from `Device` and `DeviceModel` other kinds of resource will be evaluated later and will not be included in the first alpha version.
 
 # Proposal
-Propose using Kubernetes [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers) to determine whether to accept or deny the request, the decision is based on how is the policy is configured, this give us chance to validate the request before persisting the object.
+Propose using Kubernetes [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers) to determine whether to accept or deny the request, the decision is based on how is the policy is configured, this gives us chance to validate the request before persisting the object.
 
 
 # Design Details
 
 ## Admission service
 
-Admission webhook is managed as an independent service, it could be built as an docker image and run as a standalone process, the feature could
+Admission webhook is managed as an independent service, it could be built as a docker image and run as a standalone process, the feature could
 be opted in by creating a k8s service with the built docker image as the backed image.
 
 The entry point the service looks like this,