anchor.diff:  
   ## <a id='remove-broker'></a>Removing a Broker ##
   
  -Attempting to remove a service broker will fail if there are service instances for any service plan in the catalog. When planning to shut down or delete a broker, make sure that you remove all service instances before you shut it down. Failure to do so will leave [orphaned service instances](api.html#orphans).
  +Attempting to remove a service broker will fail if there are service instances for any service plan in the catalog.
  +When planning to shut down or delete a broker, make sure that you remove all service instances before you shut it down.
  +Failure to do so will leave [orphaned service instances](api.html#orphans).
   
   With `cf`:
   <pre class="terminal">
  
positive.code: 
  ## <a id='rename-broker'></a>Rename a Broker ##
  
  A service broker can be renamed with the following commands. This name is used only by the Cloud Foundry operator to identify brokers, and has no relation to configuration of the broker itself.
  
  With `cf`:
  
  
negative.code: 
  Once you've implemented the [Catalog endpoint](api.html#catalog-mgmt), you'll want to see whether your services and plans are available to end users. Two steps are required:
  
  1. Register your broker with cloud controller
  2. Make plans public
  
  In order to run any of the commands below, you must be authenticated as a cloud controller admin (via the `cf login` or `gcf login` command).
  
  ## <a id='add-broker'></a>Add a Broker ##
  
  Registering a broker causes cloud controller to fetch and validate the catalog from your broker, and save the catalog to cloud controller database.
  The basic auth username and password which are provided when adding a broker are encrypted in cloud controller database.
  The Cloud Controller uses them to authenticate with the broker when making all API calls.
  Your service broker should validate the username and password sent in every request; otherwise, anyone could curl your broker to delete service instances.
  
  With `cf`:
  
  