anchor.diff:  
   ### <a id='dns-example'></a>DNS ###
   
  -In order to resolve hostnames to IP addresses, apps require DNS server 
  +In order to resolve hostnames to IP addresses, applications require DNS server 
   connectivity, which typically use port 53. Administrators should create or
   update a `dns` ASG with appropriate rules. Administrators may further restrict
   the DNS servers to specific IP addresses or ranges of IP addresses.
  
positive.code: | `description`   |An optional text field for operators managing security group rules. <%= vars.asg_desc %>
  
  
  For information about creating ASGs, see [Create ASGs](#asg-individual).
  
  ## Process for Administering ASGs
  
  The following table outlines the flow of tasks that the administrator carries out over the lifecycle of ASGs.
  Procedures for each of these tasks are given in [Procedures for Working with ASGs](#procedures) below.
  <table>
    <tr>
      <th></th>
      <th>Task</th>
      <th>For more information, see</th>
    </tr>
    <tr>
      <td>1.</td>
      <td>Review the existing ASGs. If this is a new deployment, probably these are only the <a href="#default">Default ASGs</a>.</td>
      <td><a href="#viewing">View ASGs</a></td>
    </tr>
    <tr>
      <td>2. </td>
      <td>Create new ASGs or edit existing ones.</td>
      <td><a href="#asg-individual">Create ASGs</a></td>
    </tr>
    <tr>
      <td>3.</td>
      <td>Bind the new ASG to containers or update the existing ASGs.</td>
      <td><a href="#updating-groups">Update ASGs</a></td>
    </tr>
    <tr>
      <td>4.</td>
      <td>If you want new ASGs to apply to apps that are already running, restart those apps.</td>
      <td><a href="#binding-groups">Binding ASGs</a></td>
    </tr>
    <tr>
      <td>5.</td>
      <td>If you need to delete ASGs, unbind and delete them.</td>
      <td><a href="#unbinding-asgs">Unbind ASGs</a><br>
  <a href="#deleting-groups">Delete ASGs</a></td>
    </tr>
  </table>
  
  ## <a id='procedures'></a> Procedures for Working with ASGs
  
  This section provides the commands you need to create and manage ASGs.
  
  ### <a id='viewing'></a>View ASGs 
  
  Run the following commands to view information about existing ASGs:
  
  |Command                             |Output
  |---                                 |---
  |`cf security-groups`                |All ASGs
  |`cf staging-security-groups`        |All ASGs applied to the platform-wide staging ASG set
  |`cf running-security-groups`        |All ASGs applied to the platform-wide running ASG set
  |`cf security-group SG-NAME`         |All rules in the ASG specified by `SG-NAME`
  
  
  ###<a id='asg-individual'></a>Create an ASG
  
  To create an ASG, perform the following steps. 
  After the ASG is created, it must be bound to an ASG set before it takes effect.
  See [#binding-groups](Bind ASGs) below.
  
  1. Create a **rules** file: a JSON-formatted single array containing objects that describe the rules. 
     See the example below, which allows ICMP traffic of code `1` and type `0` to all destinations, 
     and TCP traffic to `10.0.11.0/24` on ports `80` and `443`:
  
      <pre>
      [
  
negative.code: $ cf bind-security-group SECURITY-GROUP ORG SPACE
  </pre>
  
  To bind an ASG to all of an organization’s existing spaces, run the command below. The `cf bind-security-group` command requires cf CLI 6.20.0 or higher.
  
  <pre class="terminal">
  $ cf bind-security-group SECURITY-GROUP ORG
  </pre>
  
  ## <a id='unbinding-groups'></a>Unbinding ASGs ##
  
  <p class='note'><strong>Note</strong>: Unbinding an ASG does not affect started applications until you restart them. To restart all of the applications in an org or a space, use the <a href="https://github.com/cloudfoundry-incubator/app-restarter">app-restarter</a> cf CLI plugin.</p>
  
  To unbind an ASG from the `default-staging` set, run the following command:
  
  