f5devcentral · 0xHiteshPatel · Oct 28, 2017 · Oct 27, 2017 · Oct 27, 2017 · Oct 27, 2017
diff --git a/docs/class1/module3/lab1.rst b/docs/class1/module3/lab1.rst
@@ -47,9 +47,9 @@ existing BIG-IP devices from your lab environment.
 Tenants & Connectors
 ^^^^^^^^^^^^^^^^^^^^
 
-iWorkflow implements a Tenant/Provider interface to enable abstracted deployment
-of L4-7 into various environment.  In conjunction iWorkflow Connectors serve as
-the L1-3 Network and Device Onboarding automation component in the automation
+iWorkflow implements a Tenant/Provider interface to enable abstracted deployments
+of L4-7 Services into various environments.  In conjunction, iWorkflow Connectors 
+serve as the L1-3 Network and Device Onboarding automation component in the automation
 toolchain.  In this lab we will create a ‘BIG-IP Connector’ for the BIG-IP 
 devices in the lab environment. This connector will then allow you to drive a 
 fully automated deployment from the iWorkflow Service Catalog.
@@ -82,7 +82,7 @@ requests contained in the ``Lab 3.1 - iWorkflow Onboarding`` folder.
 
 Perform the following steps to build the cluster:
 
-#. Click the :guilabel:`Runner` button at the top right of your Postman window:
+#. Click the :guilabel:`Runner` button at the top left of your Postman window:
 
    |image97|
 

diff --git a/docs/class1/module3/lab2.rst b/docs/class1/module3/lab2.rst
@@ -40,7 +40,7 @@ The templates used in this lab all have a version number appended to the name
 in your environment.  Explicitly versioning the templates allows for migration
 between template versions in a stable manner.  Without versioning any changes
 to the template could result in *every* deployment associated with the template
-being modified at the same time.  With versioning the application owner or F5
+being modified at the same time.  With versioning, the application owner or F5
 administrator can choose to either migrate all deployments at the same time OR
 perform the migration on a per deployment manner.
 
@@ -51,7 +51,7 @@ In this task we will use the Runner to quickly create our sample Service
 Templates.
 Perform the following steps to complete this task:
 
-#. Click the :guilabel:`Runner` button at the top right of your Postman window.
+#. Click the :guilabel:`Runner` button at the top left of your Postman window.
 
 #. Select :menuselection:`F5 Programmability: Class 1 --> 
    Lab 3.2 - Create a Declarative Service Catalog` folder.
@@ -120,7 +120,7 @@ Perform the following steps to complete this task:
 
    |image50|
 
-   In the case of the fields shown in the example:
+   In the case of the fields shown in the above example:
 
    - ``pool__DefaultPoolIndex``: A value of ``0`` will be sent during a 
      deployment
@@ -182,7 +182,7 @@ Perform the following steps to complete this task:
 
 #. Finally, to assist in designing a Tenant interface, iWorkflow allows you to
    preview what the Tenant UI would look like for a Service Template.  To view
-   preview for click the :guilabel:`Tenant Preview` button:
+   the preview, click the :guilabel:`Tenant Preview` button:
 
    |image52|
 
@@ -191,7 +191,7 @@ Perform the following steps to complete this task:
    :guilabel:`Tenant Editable` fields are shown.  Because the true deployment
    details are filtered from the Tenant, the Service Deployment requires much 
    less **Domain Specific Knowledge**.  Keep in mind that while the Tenant
-   interface may be simple, you can leverage advanced functionality in the 
+   interface may be simple, you can still leverage advanced functionality in the 
    Service Template.
 
    |image53|
@@ -217,7 +217,7 @@ appropriate Monitors, Profiles and Options for the use case.
       - HTTPS Offload and Load Balancing to a Single Pool
     * - ``f5-fasthttp-lb-v1.0``
       - Performance-enhanced HTTP Load Balancing to a Single Pool
-    * - ``f5-fastl4-udp-lb-v1.0``
+    * - ``f5-fastl4-tcp-lb-v1.0``
       - Generic L4 TCP Load Balancing to a Single Pool
     * - ``f5-fastl4-udp-lb-v1.0``
       - Generic L4 UDP Load Balancing to a Single Pool

diff --git a/docs/class1/module3/lab3.rst b/docs/class1/module3/lab3.rst
@@ -90,7 +90,7 @@ Tenant API you must authenticate with a Tenant User (``tenant`` in this case).
 Perform the following steps to complete this task:
 
 #. In Postman expand the ``Lab 3.3 - Deploy L4-7 Services`` folder in the
-   collection
+   collection.
 
 #. Click the ``Authenticate and Obtain Token for Tenant User`` request and 
    examine the JSON request :guilabel:`Body`.  Notice that we are sending the
@@ -168,7 +168,7 @@ Perform the following steps to complete this task:
 
    |image60|
 
-#. Click the :guilabel:`Send` button to **Update** the Service Deployment
+#. Click the :guilabel:`Send` button to **Update** the Service Deployment.
 
 #. Update the iWorkflow Tenant UI and notice that the Service has been updated:
 
@@ -189,7 +189,7 @@ Perform the following steps to complete this task:
 #. We will send a ``GET`` request to the Resource URI for the existing 
    deployment.
 
-#. Click the :guilabel:`Send` button to **Read** the Service Deployment
+#. Click the :guilabel:`Send` button to **Read** the Service Deployment.
 
 #. Examine the JSON Response :guilabel:`Body` to see the state of the current
    Service Deployment:
@@ -206,7 +206,7 @@ Perform the following steps to complete this task:
 #. We will send a ``DELETE`` request to the Resource URI for the existing 
    deployment.
 
-#. Click the :guilabel:`Send` button to **Delete** the Service Deployment
+#. Click the :guilabel:`Send` button to **Delete** the Service Deployment.
 
 #. Update the iWorkflow Tenant UI and verify that the Service has been deleted:
 
@@ -240,7 +240,7 @@ modifying the requests as needed.
       - HTTPS Offload and Load Balancing to a Single Pool
     * - ``f5-fasthttp-lb``
       - Performance-enhanced HTTP Load Balancing to a Single Pool
-    * - ``f5-fastl4-udp-lb``
+    * - ``f5-fastl4-tcp-lb``
       - Generic L4 TCP Load Balancing to a Single Pool
     * - ``f5-fastl4-udp-lb``
       - Generic L4 UDP Load Balancing to a Single Pool

diff --git a/docs/class1/module3/module3.rst b/docs/class1/module3/module3.rst
@@ -38,8 +38,8 @@ further abstract Application Services and deliver those services, with
 a **Declarative** interface to Consumers.
 
 When moving to an iWorkflow based toolchain it’s important to understand
-that L1-3 Automation (Device Onboarding, Networking, etc) and L4-7
-(Deployment of Virtual Servers, Pools, etc) are separated and delivered
+that automation in L1-3 (Device Onboarding, Networking, etc) and L4-7
+(Deployment of Virtual Servers, Pools, etc) is separated and delivered
 by different features.
 
 Layer 1-3 Networking and Device Onboarding
@@ -65,9 +65,9 @@ iWorkflow enables generic functionality in all of these environments by using
 a **BIG-IP Cloud Connector**.  This connector allows iWorkflow to utilize
 BIG-IP devices running on any of these environments.
 
-.. NOTE:: F5 BIG-IP also supports integration with Container Ecosystems,
-   however, in these environments iWorkflow may use may not be required.  For
-   more information you can refer to:
+.. NOTE:: F5 BIG-IP also supports integration with Container Ecosystems.
+   However, in these environments iWorkflow may not be required.  For more
+   information you can refer to:
 
    - Container Ecosystems:
 
@@ -84,23 +84,23 @@ Layer 4-7 Application Service Delivery
 
 L4-7 Application Service Delivery is accomplished by:
 
--  **Declarative:** Consuming F5 iApp templates from BIG-IP devices and
+-  **Declarative:** Consuming F5 iApp templates on BIG-IP devices and
    creating a Service Catalog.
 
 -  **Imperative:** Consuming the iWorkflow REST Proxy to drive API calls to
-   BIG-IP devices
+   BIG-IP devices.
 
 The labs in the module will focus on the high level features in place to
 achieve full L4-7 automation. As mentioned above, iApp Templates are a key
 component of the chain of linked tools (toolchain) we are building.
 
 In this Module we will focus on building a **Service Catalog** using the App
 Services iApp template you learned about in Module 2.  The focus in Module 2
-was showing how to drive rich deployments, however, a large amount of F5
-**Domain Specific Knowledge** was still required to drive the deployments.
-From a conceptual view iApp templates alone do not fully satisfy the requirement
+was to show how to deploy advanced configurations. However, a large amount of F5
+**Domain Specific Knowledge** was still required to build each deployment.
+From a conceptual point of view, iApp templates alone do not fully satisfy the requirement
 for a fully **Declarative** interface because while the iApp template simplifies
-the underlying **Imperative** actions it does not allow the administrator to
+the underlying **Imperative** actions, it does not allow the administrator to
 build an **Interface** that minimizes or eliminates the need for **Domain
 Specific Knowledge**.