Joshua MacDonald

Let's please leave this open as long as these responses aren't handled in http/proto and http/json.

The suggested clarification is welcome. As for the additional context, I feel that support for negative observations is a post-1.0 issue to be addressed.

~Thank you @MrAlias! Your proposal sounds good to me.~ EDIT: I have apparently mis-understood this discussion! @MrAlias explained how I had not understood the discussion on Tuesday, sorry.

I believe we are debating an implementation detail. The quoted sentence, > Metric Exporters always have an associated MetricReader. The aggregation and temporality properties used by the OpenTelemetry Metric SDK...

I am willing to help fix the specification to clarify that MetricReaders are responsible for configuration and that how the defaults are determined is an implementation detail. I wrote the...

How can `FLAG_NO_RECORDED_VALUE` not be considered part of a stability guarantee? Are you saying that you'd like to reserve the right to change the name of the symbol so that...

Yes, it looks like we will revert all changes stemming from the change of "direction", which I think means reverting the name change here.

At Lightstep, we use a (hash of the) combination of all identifying fields, including for example metric datapoint timestamps, to compute an "idempotency key" for OTLP data. We use this...

@alexander-shepel I support the basic claim that without a request identifier in OTLP, that implementing correct at-most-once aggregation logic on the write path is fundamentally expensive. Lightstep would prefer if...

See https://github.com/open-telemetry/oteps/pull/148