anchor.diff:  (NAT boxes are systems responsible for Network Address Translation, not to be confused with the NATS messaging protocol.)
   
   You also need to obtain the special URL, called a syslog URL, that the service makes available as an endpoint for incoming log data.
  -The URL is special because its protocol is `syslog`.
  -It also includes a port number.
  +This URL has a protocol of `syslog` and includes a port number.
   For example:
   
    `syslog://logs.example.com:1234`
  
positive.code: 
  ## <a id='cli'></a>Preparation: Viewing Logs in the Command Line Interface ##
  
  The `cf logs <app_name>` command enables you to view logs in the CLI.
  You can view all the logging information that Loggregator has or receives, or filter it using shell commands.
  The log output examples below are edited for brevity.
  
  **Note**: The filtering examples use the Linux `grep` command.
  Depending on your operating system and shell, you may need to use a different command or syntax.
  
  1. cf logs <app_name> displays all of the logging information that Loggregator receives in (almost) real time.
  
  	<pre class="terminal">
  		$ cf logs nifty-gui
  
negative.code: In this case, you create a user-provided service instance using the `cups` command with the `-l` option and the syslog URL you obtained earlier.
  See [User-Provided Services] (./user-provided.html#user-cups).
  
  Now that the service instance and the syslog drain exist, you are ready to bind the service instance to the app.
  
  ### <a id='bind'></a>Bind the service instance to the application ###
  
  Use the `cf bind-service` command as described in [Binding User-Provided Service Instances to Applications](user-provided.html#cups-example).
  
  ## <a id='verify'></a>Verifying that Logs are Draining to a Service ##
  
  _Let's provide a few clues about what to do once we've completed the procedure above._
  
  ## <a id='types'></a> Types of Logs ##
  
  