spec: revert #c88bed5

Accidentally pushed a commit to master via the github webUI. This PR
reverts the accidentally merged commit.

Author: James DeFelice

spec.md

@@ -393,18 +393,24 @@ These limits apply for messages generated by both COs and plugins.
 * A `repeated` or `map` field listed as `REQUIRED` MUST contain at least 1 element.
 * A field noted as `OPTIONAL` MAY be specified and the specification SHALL clearly define expected behavior for the default, zero-value of such fields.
 
-Scalar fields, even REQUIRED ones, will be defaulted if not specified and any field set to the default value will not be serialized over the wire as per [proto3](https://developers.google.com/protocol-buffers/docs/proto3#default).
+Scalar fields, even REQUIRED ones, will be defaulted if not specified, and any field set to the defaul value will not be serialized over the wire as per [proto3](https://developers.google.com/protocol-buffers/docs/proto3#default).
 
 #### Timeouts
 
 Any of the RPCs defined in this spec MAY timeout and MAY be retried.
-The CO MAY chooses the maximum time it is willing to wait for a call, how long it waits between retries, and how many time it retries (these values are not negotiated between plugin and CO).
-
-Idempotency requirements ensure that a retried call with the same fields continues where it left off when retried.
-The only way to cancel a call is to issue a "negation" call if one exists.
-For example, issue a `ControllerUnpublishVolume` call to cancel a pending `ControllerPublishVolume` operation, etc.
-In some cases, a CO MAY NOT be able to cancel a pending operation because it depends on the result of the pending operation in order to execute the "negation" call.
-For example, if a `CreateVolume` call never completes then a CO may not have the `volume_id` to call `DeleteVolume` with.
+The CO MAY chooses the maximum time it is willing to wait for a call,
+how long it waits between retries, and how many time it retries (these
+values are not negotiated between plugin and CO).
+
+Idempotency requirements ensure that a retried call with the same fields
+continues where it left off when retried. The only way to cancel a call
+is to issue a "negation" call if one exists (for example, issue a
+`ControllerUnpublishVolume` call to cancel a pending
+`ControllerPublishVolume` operation, etc.). In some cases, a CO MAY not
+be able to cancel a pending operation, because it depends on the result
+of the pending operation in order to execute the "negation" call (for
+example, if a `CreateVolume` call never completes, a CO may not have the
+`volume_id` to call `DeleteVolume` with).
 
 ### Error Scheme