anchor.diff:  
   ### <a id='shared-domains'></a>Shared Domains ###
   
  -Admins manage shared domains and those domains are available to users in all orgs. An admin can offer multiple shared domains to users, configuring one as the default.
  -
  -For example, an admin can offer developers the choice of creating routes for their apps from two domains by configuring <%=vars.product_short%> with the following shared domains: `<%=vars.app_domain%>` and `cf.some-company.com`. If the admin configures `<%=vars.app_domain%>` as the default, a developer who pushes the app `myapp` to <%=vars.product_short%> without specifying a route will cause <%=vars.product_short%> to create and map the route `http://myapp.<%=vars.app_domain%>` to their app.
  -
  -Requests to `http://myapp.<%=vars.app_domain%>` route immediately to the app. However, if the developer wants the app to be accessible at `myapp.cf.some-company.com`, they can create this route using the commands below and map it to the app.
  +Admins manage shared domains, which are available to users in all orgs. 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 two domains by configuring <%=vars.product_short%> with the following shared domains: `<%=vars.app_domain%>` and `cf.some-company.com`. 
  +
  +There is not technically a default shared domain. If a developer pushes an app without specifying a domain (see [Map a Route with Application Push](#map-route-on-push)), a route will be created for it from the first shared domain created in the system. 
  +
  +Shared domains can be either HTTP or TCP.  
  +
  +<p class="note"><strong>Note:</strong> By default, <%=vars.product_short%> only supports routing of HTTP requests to applications. Operators may optionally enable support for routing of non-HTTP TCP requests by deploying the <a href="https://github.com/cloudfoundry-incubator/cf-routing-release">CF Routing BOSH release</a> and creating a TCP shared domain. For more information about shared domains, see the <a href="#shared-domains">Shared Domains</a> section.</p>
   
   #### <a id='create-private-domain'></a>Create a Shared Domain ####
   
  
positive.code:     </tr>
  </table>
  
  The router does not use a route to match requests until it is mapped to an app. In the above example, `products.<%=vars.app_domain%>` is a route, but until it is mapped to an app, requests for it receive a 404.
  
  The routing tier knows the location of instances for apps mapped to routes. Once the routing tier determines a route as the best match for a request, it makes a load-balancing calculation using the round-robin algorithm, and forwards the request to an instance of the mapped app.
  
  Developers can map many apps to a single route, resulting in load-balanced requests for the route across all instances of all mapped apps. This approach enables the blue/green zero-downtime deployment strategy. Developers can also map an individual app to multiple routes, enabling access to the app from many URLs.
  
  Routes belong to a space, so that developers can only map apps in the same space to a route. Routes are globally unique, so that developers in one space cannot create a route with the same URL as developers in another space, regardless of which orgs control these spaces.
  
  ### <a id='http-vs-tcp-routes'></a>HTTP vs TCP Routes
  
  
negative.code: <pre class="terminal">
  $ cf create-shared-domain <%=vars.app_domain%>
  </pre>
  
  
  #### <a id='delete-shared-domain'></a>Delete a Shared Domain ####
  
  