anchor.diff:  
   The first endpoint that a broker must implement is the service catalog. Cloud Controller will initially fetch this endpoint from all brokers and make adjustments to the user-facing service catalog stored in the Cloud Controller database. If the catalog fails to initially load or validate, Cloud Controller will not allow the operator to add the new broker, and should give a meaningful error message. Cloud Controller will also update the catalog whenever a broker is updated, so you can use `update-service-broker` with no changes to force a catalog refresh.
   
  -When Cloud Controller fetches a catalog from a broker, it will compare the `unique_id` for services and plans with what is in the  Cloud Controller database. If a service or plan in the broker catalog has a `unique_id` which is not present in the database, a new record will be added to the database. If services or plans in the database are found with `unique_id`s that match the broker catalog, Cloud Controller will update update the records to match the broker’s catalog.
  +When Cloud Controller fetches a catalog from a broker, it will compare the broker's id for services and plans with the `unique_id` values for services and plans in the Cloud Controller database. If a service or plan in the broker catalog has an id which is not present amongst the `unique_id` values in the database, a new record will be added to the database. If services or plans in the database are found with `unique_id`s that match the broker catalog's id, Cloud Controller will update update the records to match the broker’s catalog.
   
   If the database has plans which are not found in the broker catalog, and there are no associated service instances, Cloud Controller will remove these plans from the database. If there are provisioned instances, the plan will be marked “inactive” and will no longer be visible in the marketplace catalog or be provisionable. Cloud Controller will then delete services that do not have associated plans from the database.
   
  
positive.code: </tbody>
  </table>
  
  Brokers are expected to respond with `200 OK` or `201 Created` with the response body from the table below. They can also return `409 Conflict` if there is already a binding at the URL. Since this endpoint cannot be used to update resources, a broker must return a 409 if a non-identical request is made. If a broker responds with any other code, Cloud Controller will assume that the binding request failed and inform the user.
  
  <table>
  <thead>
  
negative.code: </tbody>
  </table>
  
  Brokers are expected to respond with `201 Created` with the response body from the table below. They can also return `409 Conflict` if there is already a provisioned resource at this URL. Since this endpoint cannot be used to update resource parameters, brokers must return 409 if a conflicting request is made. Ideally, a non-conflicting request (duplicate ID and params) would return 200, but brokers may simply return 409 for a duplicate ID.  If they respond with any code other than 200 or 201, CC will assume that the provision request failed and inform the user.
  
  <table>
  <thead>
  