Joshua MacDonald

> Do you have a concrete example [...]? Sure. I filed this in connection with https://github.com/open-telemetry/opentelemetry-go-contrib/issues/2624, where one appears. The Go runtime/metrics package produces one Gauge Histogram, ``` /sched/latencies:seconds Distribution...

The recommendation to use "the timestamp when a metric collection system started" was included as an option that would allow simultaneous producers of a Gauge to be detected by the...

Considering #2318, I think we should update the specification stating that start_timestamp is not used for Gauge data points. I also think we should add to the specification stating that...

Related content here: https://github.com/open-telemetry/oteps/issues/78 To support resources as an API-level concept, as in OTEP 78, requires protocol support for "more than one Resource" as you say.

~I do not feel enthusiastic about about `has_negative_measurements`.~ There could be finer-grain statements people might like to specify about their instruments, like a range between [0, 100] for example, so...

Referring to the contents of https://github.com/open-telemetry/oteps/pull/156, there are three semantics for the Sum field of a Histogram, corresponding with a Histogram of values to synchronous Counter, UpDownCounter, and Gauge API...

Taken together with #308, the pair of proposals to me suggest a new field that contains extra semantic bits, two states for Count being monotonic or not, and three states...

Lightstep's old OpenTracing tracers include clock correction. The server would respond with its timestamps and the client would calculate an offset. It tends to cause a lot of trouble, but...

See also https://github.com/open-telemetry/opentelemetry-specification/issues/2288

I like the idea of narrowly defining this as whether the aggregation Count matches the number of input measurements.