anchor.diff:          etc...
           ```
   
  -1. Create a `json` that contains ASG rules using your `config.yml` as input by running the following command:  
  -  * Replace `OUTPUT-FILE-NAME` with a name of your choice. 
  +1. Run the following command to create a `json` that contains ASG rules, using your `config.yml` as input:   
     <pre class="terminal">$ asg-creator create --config config.yml --output OUTPUT-FILE-NAME.json</pre>
  +  Replace `OUTPUT-FILE-NAME` with a name of your choice.
   
   1. Create an ASG by running the following command:
     1. Replace `SECURITY-GROUP-NAME` with a name of your choice.
     1. Replace `OUTPUT-FILE-NAME` with the name of the generated file from the previous step. 
     <pre class="terminal">$ create-security-group SECURITY-GROUP-NAME OUTPUT-FILE-NAME.json</pre>
   
  -1. Bind the ASG to the [default staging set](../concepts.html/asg.html#asg-sets):
  +1. Bind the ASG to the default staging set:
     <pre class="terminal">$ cf bind-staging-security-group SECURITY-GROUP-NAME</pre>
   
  -1. Bind the ASG to the [default running set](../concepts.html/asg.html#asg-sets):
  +1. Bind the ASG to the default running set:
     <pre class="terminal">$ cf bind-running-security-group SECURITY-GROUP-NAME</pre>
   
  -### <a id='service-access'></a> Part C: Create and Bind ASGs for Service Access
  -
  -Some of your developer's apps may need to communicate with a service. Follow these steps to Create ASGs that allow them to do so. 
  -
  -1. If either of the following is true, complete this section. Otherwise, your apps can already access services without restrictions and you can proceed to [Step 4: Remove the Deployment-wide Default ASG Binding](#unbind-default): 
  -  * You have a two network layout.
  -  * You chose to block the service network(s) in the previous step.
  -
  -1. Now that you have created ASGs to secure the Ops Man, Elastic Runtime, and service components, create additional ASGs to give apps access to any services they need. 
  -  <p class="note warning"><strong>WARNING</strong>: If you have the two network layout, then each time you create an ASG that allows apps to access a new port/protocol, you further expose the Elastic Runtime component VMs. This is a limitation of a two network layout. For guidance on network topology, see <a href="../refarch/index.html">Reference Architectures</a>.</p>
  -  * For example, in any space where apps need to access the MySQL for PCF service, follow the steps in [Creating Application Security Groups for MySQL](http://docs.pivotal.io/p-mysql/app-security-groups.html). 
  -  * For more information on creating and binding ASGs, see the following:
  -      * [Procedures for Working with ASGs](../concepts/asg.html#procedures)
  -      * [Typical ASGs](../concepts/asg.html#typical-groups) 
  +#### <a name='service-access'></a> Part C: Create and Bind ASGs for Service Access
  +
  +<p class="note"><strong>Note</strong>: This part is only necessary if you blocked apps from a network that hosts services in the previous part. If you did not block apps from a network that hosts services, proceed to <a href="undbind-default">Step 4: Remove the Default ASG</a>.
  +</p>
  +
  +<p class="note warning"><strong>WARNING</strong>: In the two network layout, Elastic Runtime and services share the same network. This means that each time you create an ASG that allows apps to access a new port/protocol within the network, you further expose the Elastic Runtime component VMs. This is a limitation of a two network layout. For guidance on network topology, see <a href="../refarch/index.html">Reference Architectures</a>.</p>
  +
  +Now that you have created ASGs to secure the Ops Man, Elastic Runtime, and service components, work with developers to create additional ASGs that give apps access to the services they need. 
  +  
  +For example, in any space where apps need to access the MySQL for PCF service, follow the steps in [Creating Application Security Groups for MySQL](http://docs.pivotal.io/p-mysql/app-security-groups.html). 
  +
  +For more information on creating and binding ASGs, see the following:
  +
  +* [Procedures for Working with ASGs](../concepts/asg.html#procedures)
  +* [Typical ASGs](../concepts/asg.html#typical-groups) 
      
    
   
  -## <a id='unbind-default'></a> Step 4: Remove the Deployment-wide Default ASG Binding
  -
  -After you bind your new ASGs to the appropriate ASG sets and spaces, you can unbind the default ASG from `default-staging` and `default-running` sets:
  -
  -1. Unbind the default security group from the staging set:
  +### <a name='unbind-default'></a> Step 4: Remove the Default ASG
  +
  +Now that you have bound new ASGs to determine outbound traffic rules, you no longer need the default ASG bindings that allow apps to send traffic to any IP.
  +
  +1. Unbind the default ASG from the staging set:
       <pre class="terminal">$ cf unbind-staging-security-group default\_security\_group</pre>
   
  -1. Unbind the default security group from the running set:
  +1. Unbind the default ASG from the running set:
       <pre class="terminal">$ cf unbind-running-security-group default\_security\_group</pre>
   
   
  -## <a id='typical'></a> Step 5: Restart your Apps to Apply the ASGs
  +### <a name='restart'></a> Step 5: Restart your Apps
   
   To apply the ASG changes, you must restart all of the apps in your deployment. To mitigate app downtime during the restart, Pivotal recommends a [blue-green](../devguide/deploy-apps/blue-green.html) deployment strategy.
   
   <p class="note"><strong>Notes</strong>: You do not need to restart the apps in the <code>system</code> org.</p>
   
  -1. Restart a few apps individually to test that they still work correctly with the new ASGs in place. If an app does not work as expected, you likely must create another ASG that allows the app to send traffic to a service it requires. 
  +1. Work with developers to restart a few of their apps individually and test that they still work correctly with the new ASGs in place. If an app does not work as expected, you likely must create another ASG that allows the app to send traffic to a service it requires. 
     <p class="note"><strong>Note</strong>: To quickly roll back to the original overly-permissive state, you can re-bind the <code>default\_security\_group</code> ASG to the <code>default-staging</code> and <code>default-running</code> sets. You must then restart your apps to re-apply the original ASGs.</p>
   
  -1. Restart the rest of your apps. Optionally, you can use the [app-restarter cf CLI plugin](https://github.com/cloudfoundry-incubator/app-restarter) to restart all apps in a particular space, org, or deployment.+1. Restart the rest of the apps running on your deployment. Optionally, you can use the [app-restarter cf CLI plugin](https://github.com/cloudfoundry-incubator/app-restarter) to restart all apps in a particular space, org, or deployment.
positive.code: 
  1. Record the **CIDR** for each network.
  
  ### <a id='initial-asgs'></a> Part B: Create and Bind ASGs for your Network Layout
  
  Create ASGs that block apps from sending traffic to the networks that host Ops Manager, Elastic Runtime, and any services installed. 
  
  1. Create a `config.yml` containing the appropriate content for your network layout and replace the indicated values with the CIDRs you gathered:
    * **Two Network Layout**:
  
negative.code:     </tr>
    </table>
  
  1. If your network layout includes two or more networks, continue [Step 2: Enxure Access for PCF System Apps](#bind-default).
  
  ### <a name='bind-default'></a> Step 2: Ensure Access for PCF System Apps ##
  
  Follow these steps to apply the default ASG to the `system` org. This provides network access to PCF system apps without restrictions, which enables them to continue functioning properly after you perform [Step 4: Remove the Deployment-wide Default ASG Binding](#unbind-default).
  
  1. Bind the default ASG to the [staging set](../concepts.html/asg.html#asg-sets) in the `system` org:
      <pre class="terminal">$ cf bind-staging-security-group default\_security\_group system</pre>
  
  1. Bind the default ASG to the [running set](../concepts.html/asg.html#asg-sets) in the `system` org:
      <pre class="terminal">$ cf bind-running-security-group default\_security\_group system</pre>
  
  ### <a name='initial'></a> Step 3: Create New ASGs ##
  
  Follow these steps to create ASGs that block apps from accessing PCF components and create any additional ASGs that allow apps to access the services they require. 
  
  #### <a name='get-cidrs'></a> Part A: Record CIDRs
  
  Gather the CIDRs for each network in your deployment:
  
  