Ted Young

> If more than one instrumentation library considers themselves the logical HTTP client, how should that be handled? Ideally, the higher level client should presume that instrumentation for the lower...

Good points. The model I was describing works better on the server side; on the client side it is difficult. It would be good to see some examples.

I agree that trace level attributes would be a good addition to OTel, but to me session IDs still look like they are resources: * A user session applies to...

Yes I totally agree we need to prototype as part of making this proposal! We have a prototype implementation in the works, taking the following approach: * Extract resources into...

This is definitely useful, but should be created in it's own repo under https://github.com/opentracing-contrib/ @rnburn may take this on soon, but we always welcome community contributions if you would like...

We may want to move this to a cross-language discussion as part of Trace Identifiers: https://github.com/opentracing/specification/issues/123

The real answer is to use an actual image of a graph, with edges and a legend. I don't really feel like this is better or worse.

I would +1 to having `log.priority` as a semantic convention. But due to opentracing's decoupled nature, may I suggest it work like the following: - there be a suggested range,...

Hi @felixbarny. I agree that object pooling (and low overhead/GC-avoidance in general) is a worthy goal to pursue. But I'm concerned about safety. Right now, the intention in the spec...

I would want to see us sit at a stable v1 before considering a 1.8+ API. In that sense, we maintain 1.6 compatibility "forever."