anchor.diff:  
   ## <a id='typical-groups'></a>Typical ASGs ##
   
  -Below are examples of typical ASGs. Configure your ASGs in accordance with your organization's network access policy for untrusted applications.
  +Below are examples of typical ASGs. Configure your ASGs in accordance with your organization's network access policy for untrusted apps.
   
   |ASG                   |For access to
   |---                   |---
  
positive.code: 
  ### <a id='public-networks-example'></a>Public Networks ###
  
  Applications often require public network connectivity to retrieve application dependencies, or to integrate with services available on public networks. Example application dependencies include public Maven repositories, NPM, RubyGems, and Docker registries.
  
  <p class='note'><strong>Note</strong>: You should exclude IaaS metadata endpoints, such as <code>169.254.169.254</code>, because the metadata endpoint can expose sensitive environment information to untrusted applications. The <code>public_networks</code> example below accounts for this recommendation.</p>
  
  Example `public_networks` ASG:
  
  
negative.code: 
  _This page assumes you are using [cf Command Line Interface tool](https://github.com/cloudfoundry/cli) (cf CLI) v6.4.0 or later._
  
  
  ## <a id='introduction'></a>Introduction ##
  
  This topic provides an overview of Application Security Groups (ASG)s and describes how to 
  manage and administer them. 
  
  Most of the procedures in this topic require admin role. 
  Other roles are limited to viewing ASGs.
  
  ###ASGs
  
  ASGs are a collections of egress rules that specify the protocols, ports, and IP address ranges 
  where containers (for either apps or tasks) send traffic. 
  Because ASGs define *allow* rules, their order of evaluation is unimportant when multiple ASGs 
  apply to the same space or deployment. 
  Containers use these rules to filter and log outbound network traffic. 
  ASGs apply to both Buildpack-based and Docker-based containers in both the app and task lifecycle phases.
  
  When apps or tasks begin staging, they need traffic rules permissive enough 
  to allow them to pull resources from the network. 
  After an app or task is running, the traffic rules can be more restrictive and secure. 
  To distinguish between these two security requirements, 
  administrators can define one ASG for app and task staging, and another for app and task runtime. 
  
  To provide granular control when securing a deployment, an administrator can assign ASGs to 
  apply to all containers across a deployment or to specific spaces within a deployment.
  
  ASGs can be complicated to configure correctly, especially when the specific IPs listed in the group change. 
  To simplify securing a deployment while still permitting apps to reach external services, 
  operators can deploy the services into a subnet that is separate from their Cloud Foundry deployment. 
  Then the operators can create ASGs for the apps that whitelist those service subnets, while denying access to any VMs hosting other apps.
  
  For examples of ASGs, see <a href="#typical-groups">Typical ASGs</a> below.
  
  