Remove span status

specification/trace/api.md

@@ -249,7 +249,6 @@ the entire operation and, optionally, one or more sub-spans for its sub-operatio
 - A list of [`Link`s](#add-links) to other `Span`s
 - A list of timestamped [`Event`s](#add-events)
 - A [`Status`](#set-status).
-- A [`Status Source`](#set-status-source).
 
 The _span name_ concisely identifies the work represented by the Span,
 for example, an RPC method name, a function name,
@@ -574,7 +573,7 @@ calling of corresponding API.
 ## Status
 
 `Status` interface represents the status of a finished `Span`. It's composed of
-a canonical code, an optional descriptive message, and a source.
+a canonical code, and an optional descriptive message.
 
 ### StatusCanonicalCode
 
@@ -587,31 +586,25 @@ codes](https://github.com/grpc/grpc/blob/master/doc/statuscodes.md):
 - `Error`
   - The operation contains an error.
 - `Ok`
-  - The operation has been validated to have completed successfully.
+  - The operation has been validated by an Application developers or Operator to 
+    have completed successfully, or contain 
 
 The status code SHOULD remain unset, except for the following circumstances:
 
-### StatusSource
-The `StatusSource` represents the origin of the status code, and which rules 
-apply for setting it.
+When the status is set to `ERROR` by Instrumentation Libraries, the status codes 
+SHOULD be documented and predictable. The status code should only be set to `ERROR` 
+according to the rules defined within the semantic conventions. For operations 
+not covered by the semantic conventions, Instrumentation Libraries SHOULD 
+publish their own conventions, including status codes. 
 
-- `Instrumentation`
-  - Spans generated by Instrumentation Libraries.
-- `User`
- - Spans generated or modified by the Application Developer or Operator.
+Generally, Instrumentation Libraries SHOULD NOT set the status code to `Ok`, 
+unless explicitly configured to do so. Instrumention libraries SHOULD leave the 
+status code as `Unset` unless there is an error, as described above.
 
-When the status source is `Instrumentation`, status codes SHOULD be documented 
-and predictable. The status code should only be set to `ERROR` according to the rules 
-defined within the semantic conventions. For operations not covered by the semantic 
-conventions, Instrumentation Libraries SHOULD publish their own conventions, 
-including status codes. 
+Application developers and Operators may set the status code to `Ok`. 
 
-When the status source is set to `Instrumentation`, there is no need to ever 
-set the status code to `Ok`. `Unset` and `Ok` SHOULD be treated as equivalent 
-when the status source is `Instrumentation`.
-
-When the status source is set to `User`, the statuses `Error` and `Ok` SHOULD be
-treated as an override for any other error analysis.
+Analysis tools SHOULD respond to an `Ok` status by supressing any errors they 
+would otherwise generate. For example, to supress noisy errors such as 404s.
 
 ### Status creation
 
@@ -624,7 +617,6 @@ Required parameters
 Optional parameters
 
 - Description of this `Status`.
-- A `StatusSource` value.
 
 ### GetCanonicalCode
 
@@ -639,9 +631,6 @@ Languages should follow their usual conventions on whether to return `null` or a
 
 Returns true if the canonical code of this `Status` is `Error`, otherwise false.
 
-### GetStatusSource
-Returns the `StatusSource`.
-
 ## SpanKind
 
 `SpanKind` describes the relationship between the Span, its parents,