diff --git a/release_notes/ocp-4-17-release-notes.adoc b/release_notes/ocp-4-17-release-notes.adoc
index cb5d67af144b..8bd08e230bc0 100644
--- a/release_notes/ocp-4-17-release-notes.adoc
+++ b/release_notes/ocp-4-17-release-notes.adoc
@@ -1924,13 +1924,13 @@ With this update, the plugin checks the local cache during the disk-to-mirror pr
 [id="ocp-4-17-rhcos-bug-fixes_{context}"]
 ==== {op-system-first}
 
-* Previously, LUKS encryption on a system using 512 emulation disks caused provisioning to fail at the `ignition-ostree-growfs` step of the process because of an alignment bug in `sfdisk` when growing a partition. With this release, the `ignition-ostree-growfs` script can now detect this situation and fix the alignment automatically. As a result, the system no longer fails during provisioning. (link:https://issues.redhat.com/browse/OCPBUGS-35410[*OCPBUGS-35410*])
+* Previously, LUKS encryption on a system using 512 emulation disks caused provisioning to fail at the `ignition-ostree-growfs` step because of an `sfdisk` alignment issue. With this release, the `ignition-ostree-growfs` script detects this situation and fixes the alignment automatically. As a result, the system no longer fails during provisioning. (link:https://issues.redhat.com/browse/OCPBUGS-35410[*OCPBUGS-35410*])
 
-* Previously, a bug in the `growpart` utility caused a LUKS device to become locked and unable to open. This prevented the system from booting and entering into an emergency mode. With this release, the call to the `growpart` utility is removed and the system successfully boots without issue. (link:https://issues.redhat.com/browse/OCPBUGS-33124[*OCPBUGS-33124*])
+* Previously, a bug in the `growpart` utility caused a LUKS device to lock. This caused the system to boot into an emergency mode. With this release, the call to the `growpart` utility is removed and the system successfully boots without issue. (link:https://issues.redhat.com/browse/OCPBUGS-33124[*OCPBUGS-33124*])
 
-* Previously, if a new deployment was done at the OSTree level on the host, which is identical to the current deployment but on a different stateroot, OSTree saw them as equal. This behavior prevented updating the bootloader when the `set-default` command was invoked, because OSTree did not recognize the two stateroots as a differentiating factor for deployments. With this release, the OSTree logic is modified to consider the stateroots. As a result, this allows OSTree to properly set the default deployment to a new deployment that has different stateroots. (link:https://issues.redhat.com/browse/OCPBUGS-30276[*OCPBUGS-30276*])
+* Previously, if a new deployment was done at the OSTree level on the host, which is identical to the current deployment on a different stateroot, OSTree identified them as equal. This behavior prevented the bootloader from updating when the `set-default` command was invoked, because OSTree did not recognize the two stateroots as a differentiating factor for deployments. With this release, OSTree's logic is modified to consider the stateroots. As a result, OSTree properly sets the default deployment to a new deployment that has different stateroots. (link:https://issues.redhat.com/browse/OCPBUGS-30276[*OCPBUGS-30276*]) 
 
-////
+//// 
 [discrete]
 [id="ocp-4-17-scalability-and-performance-bug-fixes_{context}"]
 ==== Scalability and performance