Christian Neumüller

Not knowing a use case but knowing that it severely limits our possibilities to change stuff around that would be wire-compatible for the binary serialization (e.g. attribute names, string vs...

invoked_region might not be the ideal name if we also want to use the attribute to e.g. record the region from which some FaaS invocation was triggered. Maybe cloud.peer_region or...

We might also want to consider the (invoked/peer/remote) account_id here as a complement to the callers cloud.account_id, but that might be considered a separate issue.

@bogdandrutu > I think you can use the presence of the end timestamp in the SpanData to determine if the Span is still in-process or finished I don't think that...

I added an example Java implementation in open-telemetry/opentelemetry-java#697.

There is a "Z pages" feature implemented in some languages, e.g. Java that allows you to view in-progress spans. Also, the spec now allows you to react to a span...

> If caller creates an Internal span for logical call, all 'physical' HTTP spans could all be nicely grouped under it and there is no need in coordination - this...

> it should be possible to separate 'real' rpc calls from logical ones. If using the rule "logical plus potentially real if the root client, otherwise physical" is not enough,...

> attributes that may affect head-based sampling should be supplied to the sampler There is still an currently unused attribute for that in the semantic convention generator: https://github.com/open-telemetry/build-tools/blob/c7067fa1f0a5c61756dcb93cbc56af566992ab4f/semantic-conventions/src/opentelemetry/semconv/model/semantic_attribute.py#L115 (https://github.com/open-telemetry/opentelemetry-specification/pull/571#discussion_r412260671)

> each try or redirect is an HTTP span, it has a unique context that must be propagated downstream - HTTP clients don’t control how their APIs are used and...