diff --git a/specs/mitaka/implemented/zhaw-load-consolidation.rst b/specs/mitaka/implemented/zhaw-load-consolidation.rst
index c0a4862..78c6fc0 100644
--- a/specs/mitaka/implemented/zhaw-load-consolidation.rst
+++ b/specs/mitaka/implemented/zhaw-load-consolidation.rst
@@ -35,8 +35,8 @@ Use Cases
 The use case is one in which the `Administrator`_ wants to perform a load
 consolidation on the `resources`_ to reduce the amount of underutilized
 servers. The Administrator invokes Watcher with the `Goal`_ of
-“VM_WORKLOAD_CONSOLIDATION”. Watcher then executes the `Strategy`_
-“VM_WORKLOAD_CONSOLIDATION_STRATEGY”. It then presents a set of `Actions`_
+"VM_WORKLOAD_CONSOLIDATION". Watcher then executes the `Strategy`_
+"VM_WORKLOAD_CONSOLIDATION_STRATEGY". It then presents a set of `Actions`_
 to the  Administrator. The Administrator then approves the recommended
 `action plan`_ - typically VM live-migration actions - and instructs Watcher
 to perform the actions.
@@ -50,8 +50,8 @@ Proposed change
 ===============
 
 The proposed change is to add a new Goal and a new Strategy to Watcher.
-The new Goal is “VM_WORKLOAD_CONSOLIDATION” and the new Strategy is
-“VM_WORKLOAD_CONSOLIDATION_STRATEGY”. The new Strategy is designed to be a
+The new Goal is "VM_WORKLOAD_CONSOLIDATION" and the new Strategy is
+"VM_WORKLOAD_CONSOLIDATION_STRATEGY". The new Strategy is designed to be a
 lightweight consolidation mechanism which can be tuned based on experience; it
 also operates quickly. The purpose of the strategy is to move the aggregate
 operating point of the `Cluster`_ to increase the number of servers with
diff --git a/specs/newton/implemented/sd-strategy.rst b/specs/newton/implemented/sd-strategy.rst
index 02458e2..a0f2f68 100644
--- a/specs/newton/implemented/sd-strategy.rst
+++ b/specs/newton/implemented/sd-strategy.rst
@@ -106,7 +106,7 @@ the standard deviation in a cluster best. That option is added
 to the map of migration options, that afterwards gets sorted
 by standard deviation in ascending order. From the resulting list
 we iteratively take a host/vm pair and place it into solution with
-action “MIGRATION”. We compare the resulting deviations of CPU and RAM
+action "MIGRATION". We compare the resulting deviations of CPU and RAM
 to the threshold values. If the resulting deviations are less than
 the threshold values, the cycle stops and the resulting action plan
 is sent to Watcher Applier.
@@ -210,4 +210,4 @@ No history.
 .. _action plan: https://factory.b-com.com/www/watcher/doc/watcher/glossary.html#action-plan
 .. _watcher input parameters: https://blueprints.launchpad.net/watcher/+spec/optimization-threshold
 .. _cluster: https://factory.b-com.com/www/watcher/doc/watcher/glossary.html#cluster
-.. _optimization threshold: https://blueprints.launchpad.net/openstack/?searchtext=optimization-threshold
\ No newline at end of file
+.. _optimization threshold: https://blueprints.launchpad.net/openstack/?searchtext=optimization-threshold