anchor.diff:  
   This example displays three available domains: a shared HTTP domain `<%=vars.app_domain%>`, a shared TCP domain `<%=vars.tcp_app_domain%>`, and a private domain `<%=vars.private_app_domain%>`. See [Shared Domains](#shared-domains) and [Private Domains](#private-domains).
   
  -### <a id='http-vs-tcp-shared-domains'></a>HTTP vs. TCP Domains ###
  +### <a id='http-vs-tcp-shared-domains'></a> HTTP vs. TCP Domains
   
   HTTP domains indicate to a developer that only requests using the HTTP protocol will be routed to applications mapped to routes created from the domain. Routing for HTTP domains is layer 7 and offers features like custom hostnames, sticky sessions, and TLS termination.
   
   TCP domains indicate to a developer that requests over any TCP protocol, including HTTP, will be routed to applications mapped to routes created from the domain. Routing for TCP domains is layer 4 and protocol agnostic, so many features available to HTTP routing are not available for TCP routing. TCP domains are defined as being associated with the TCP Router Group. The TCP Router Group defines the range of ports available to be reserved with TCP Routes. Currently, only Shared Domains can be TCP.
   
  -<p class="note"><strong>Note</strong>: By default, <%=vars.product_short%> only supports routing of HTTP requests to applications. </p>
  -
  -### <a id='shared-domains'></a>Shared Domains ###
  +<p class="note"><strong>Note:</strong> By default, <%=vars.product_short%> only supports routing of HTTP requests to applications. </p>
  +
  +### <a id='shared-domains'></a> Shared Domains
   
   Admins manage shared domains, which are available to users in all orgs of a <%=vars.product_short%> deployment. An admin can offer multiple shared domains to users. For example, an admin may offer developers the choice of creating routes for their apps from `<%=vars.app_domain%>` and `cf.some-company.com`.
   
  
positive.code: $ cf delete-shared-domain example.com
  </pre>
  
  #### <a id='internal-domains'></a>Internal Domain ####
  
  The internal domain is a special type of shared domain used for app communication internal to the platform. When you enable service discovery, the internal domain `apps.internal` becomes provided for your use.
  
  Administrators can configure multiple internal domains.
  
  ### <a id='private-domains'></a>Private Domains ###
  
  Org Managers can add private domains, or custom domains, and give members of the org permission to create routes for privately registered domain names. Private domains can be shared with other orgs, enabling users of those orgs to create routes from the domain.
  
  Private domains can be HTTP or HTTPS only. TCP Routing is supported for Shared Domains only.
  
  #### <a id='create-private-domain'></a>Create a Private Domain ####
  
  Org Managers can create a private domain with the following command:
  <pre class="terminal">
  $ cf create-domain my-org <%=vars.private_app_domain%>
  </pre>
  
  Org Managers can create a private domain for a subdomain with the following command:
  <pre class="terminal">
  $ cf create-domain my-org foo.<%=vars.private_app_domain%>
  </pre>
  
  #### <a id='sharing-private-domains'></a>Sharing a Private Domain with One or More Orgs ####
  
  Org Managers can grant or revoke access to a private domain to other orgs if they have permissions for these orgs with the following commands:
  
  <pre class="terminal">
  $ cf share-private-domain test-org <%=vars.private_app_domain%>
  
negative.code:   </tr>
  </table>
  
  #### <a id='map-internal-route'></a> Map an Internal Route to an App
  
  <p class="note"><strong>Note:</strong> This feature is currently experimental.</p>
  
  You can map an internal route to any app. This internal route allows your app to communicate with other apps without leaving the platform. Once mapped, this route becomes available to all other apps on the platform.
  
  