Implemented enhancements from doc review

According to documentation style guide and policies, fixed wording,
style, grammar, punctuation.

Author: chabowski

adoc/SAP-EIC-Main.adoc

@@ -151,10 +151,10 @@ include::SAP-Rancher-RKE2-Installation.adoc[tags=!install-rke2-harvester]
 
 == Preparing storage
 
-In order to make storage available for Kubernetes workloads, you'll need to prepare the storage solution you want to use.
-In this chapter we'll describe how to those up and how to prepare it, so {eic} can consume it.
+To make storage available for Kubernetes workloads, prepare the storage solution you want to use.
+In this chapter, we will describe how to set this up and how to prepare it for consumption by {eic}.
 
-The tested storage solutions by SAP and SUSE are shown below with a link to the chapter, where we'll describe how to set them up and configure them:
+The storage solutions tested by SAP and SUSE are presented below, along with links to chapters detailing their setup and configuration.
 
 * {lh} <<Longhorn>>
 * {netapp} {trid} <<NetApp>>
@@ -184,7 +184,7 @@ NOTE: Keep in mind that the descriptions and instructions below might differ fro
 
 === Logging in to {rac}
 
-To access the {rac} you need to log in. You can do this using the console and Helm client.
+To access the {rac}, you need to log in. You can do this using the console and Helm client.
 The easiest way to do so is to use the built-in shell in {rancher}. To access it, navigate to your cluster and click *Kubectl Shell* as shown below:
 
 image::EIC-Rancher-Kubectl-Button.png[title=Rancher Shell Access,scaledwidth=99%]
@@ -204,7 +204,7 @@ helm registry login dp.apps.rancher.io/charts -u <yourUser> -p <your-token>
 
 === Installing {metallb} on Kubernetes cluster
 
-This chapter is intended to guide you through the installation and configuration of {metallb} on your Kubernetes cluster used for {eic}.
+The following chapter should guide you through the installation and configuration of {metallb} on your Kubernetes cluster used for {eic}.
 
 include::SAP-EIC-Metallb.adoc[Metallb, leveloffset=2]
 

adoc/SAP-EIC-Netapp.adoc

@@ -12,14 +12,14 @@ For more details how to install {trid} with Helm, visit https://docs.netapp.com/
 === Preparing the OS 
 
 The Kubernetes worker nodes must be prepared so PVCs can later be provisioned properly.
-Thus you need to install the following packages:
+Thus, you need to install the following packages:
 
 [source, bash, subs="attributes"]
 ----
 sudo zypper in -y lsscsi multipath-tools open-iscsi
 ----
 
-As multipathd is known to have problems on OS using the kernel-default-base packages, replace them with kernel-default:
+As multipathd is known to have problems on OS using the kernel-default-base packages, replace them with `kernel-default`:
 
 [source, bash, subs="attributes"]
 ----
@@ -42,7 +42,7 @@ sudo systemctl enable --now multipathd
 === Deploying the {trid} operator
 
 The {trid} operator is responsible to establish the connection between your {netapp} storage system and the Kubernetes cluster.
-An example of how to deploy it looks like follows:
+An example of its deployment is shown below:
 
 [source, bash, subs="attributes"]
 ----
@@ -54,10 +54,10 @@ helm install my-trident-operator netapp-trident/trident-operator --version 100.2
 
 # tag::backend-config[]
 
-=== Establish the connection between Kubernetes and the {netapp} storage
+=== Establishing the connection between Kubernetes and the {netapp} storage
 
-Before creating the link to the backend, it's recommended to store the user and password information in a Secret.
-To create such a secret you can use:
+Before creating the link to the backend, you should store the user and password information in a Secret.
+To create such a Secret, follow the example below:
 
 [source, yaml]
 ----
@@ -72,10 +72,10 @@ stringData:
   password: <password>
 ----
 
-To establish the connection between the target Kubernetes cluster and the {netapp} storage system, a so called *TridentBackendConfig* is required.
-To get more information how to set up the backend configuration, refer to https://docs.netapp.com/us-en/trident/trident-use/backend-kubectl.html#tridentbackendconfig
+To establish the connection between the target Kubernetes cluster and the {netapp} storage system, a so-called *TridentBackendConfig* is required.
+For more information how to set up the backend configuration, refer to https://docs.netapp.com/us-en/trident/trident-use/backend-kubectl.html#tridentbackendconfig
 
-The following two examples are showing what the configuration for a SAN/iscsi backend and a NAS backend looks like:
+Below are two examples demonstrating the configuration of SAN/iSCSI and NAS backends:
 
 [source, yaml]
 ----
@@ -120,16 +120,17 @@ To verify the backend was configured successfully, check the output of:
 kubectl -n trident get tbc backend-tbc-ontap-san
 ----
 
-If the connection was established, the *State* should be active and you should see a *Backend UUID*
+If the connection was established, the *State* should be active and you should see a *Backend UUID*.
 
 # end::backend-config[]
 
 //TODO example picture
 
 # tag::storageClass[]
 
-Once the backend is configured, you can create a *StorageClass* to provision Volumes to be consumed by a Persistent Volume Claim.
-Here's an example that will create a storageClass that will use an SAN/iscsi backend:
+When the backend is configured, you can create a *StorageClass* to provision Volumes to be consumed by a Persistent Volume Claim.
+Here's an example for creating a StorageClass that uses a SAN/iSCSI backend:
+
 
 [source, yaml]
 ----