Remove vague language and add details about the metrics handler

specification.md

@@ -45,21 +45,16 @@ details. This section summarizes a few key differences.
   client library provided data may lack the semantic conventions
   available in OpenTelemetry libraries.
 
-## Compatibility Requirements
-
-Given the number of fundamental design goals between OpenTelemetry
-and Prometheus, our aim is to close the gaps where possible and
-make the right compromises to meet the goals defined in this document.
-OpenTelemery and Prometheus won’t be fully compatible but we will
-enable important use cases to enable OpenTelemetry for Prometheus
-users. The following sections summarizes the expectations from
-the collector and the libraries.
+## Implementation Requirements
 
 ### Collector
 
 * Collector will implement a Prometheus remote write exporter.
-  Publishing a pull-based metrics handler with all collected
-  metrics is not a scalable approach.
+  Collector is a common metrics sink in collection pipelines where
+  metric data points are recieved and quickly "forwarded" to exporters.
+  Implementing a pull-based metrics handler will require additional
+  design work in this model to be efficient, we may follow-up
+  with improvements to enable a metrics handler.
 * Collector will support scraping and ingesting cumulative metrics.
   Prometheus doesn’t support deltas and there are cases where
   rebuilding the cumulatives from deltas is not possible/easy.
@@ -70,7 +65,7 @@ the collector and the libraries.
   OTLP-compatible exporters.
 * At each scrape, collector will produce an "up" metric as a gauge
   internally in the reciever and exporter will translate it to a
-  Prometheus up metric in the export time.
+  Prometheus up metric in the remote write exporter.
 * Collector will produce "instance" and "job" labels similar
   to the Prometheus server.
 * If a target disappears from the scrape, the collector will