BTW we need to update https://github.com/census-instrumentation/opencensus-specs/blob/master/encodings/BinaryEncoding.md#tag-context too (probably in another PR).

@bogdandrutu PTAL.

@yurishkuro PTAL.

it looks ok. My main concern is that TagTTL=0 is meant for in-process-only propagation, but it does not really address all the needs of that use case, specifically propagating arbitrary objects, of which a tag with string value is just a special case. The specification already has a section about Context, which fits the larger use case I am talking about. Given that, is TagTTL=0 actually needed? And if not, what other uses of TagTTL besides unlimited propagation?

@yurishkuro so couple of difference for what others call baggages. Tags for OC are properties associated with the current request (and we try hard to not have any business logic in these), we currently use tags with requests stats (metrics), can be associated with logs, or Spans. One example of a tag that is TTL=0 is rpc_server_method (or http_server_method), this is valid only on the current process and all signals recorded within this request can be attributed to that server method.

For the business logic things like "auth" for example we recommend people to use directly the context.

Yes I know. But taking a position that "tag == dimension on metrics" is dangerous, especially when tags can be sent upstream: my service's metrics should not be getting new dimensions just because someone from upstream added a baggage item. So there needs to be a mechanism for service owner to whitelist the tags that are allowed as metrics labels. If such mechanism exists, then TTL=0 kind of becomes unnecessary, since the whitelist can just as well take the tag value from the context directly.

Basically, I think I really dislike the TTL notion. For TTL=0, one can store the key/value in the context and not bother with "tags". TTL=1 is dubious. In fact, any TTL != infinity is semantically very vague, because it's difficult to define the exact boundary where TTL -= 1 is supposed to happen. For example, if I am using a service mesh for outbound traffic, does the transfer from my application to service mesh count as the serialization barrier (and therefore TTL -= 1)? Note that the mesh still produces exit spans on behalf of my service.

Prior to TTL change there was a concept of Local and Remote scope, essentially TTL=0 and TTL= -1 (infinity). TTL gives ability to drop a tag in a different way than a TagFilter. TTL allows control from the originator as oppose to TagFilter. For example, if service A connects to service B, C and D then it would have to configure exclude TagFilter on B,C, and D on outbound. With TTL, service A can set TTL=1 and it will get dropped on B,C and D. It doesn't need any configuration on B, C and D.
In the absence of TTL one can always use TagFilter to achieve the same result. The question is do we need another way to drop the tag?

In the absence of TTL one can always use TagFilter to achieve the same result. The question is do we need another way to drop the tag?

I'd suggest not adding another way. A filter sounds like a much better approach, explicit and unambiguous, where's TTL is quite vague as to where TTL -= 1 is supposed to happen.

In the absence of TTL one can always use TagFilter to achieve the same result.
I'd suggest not adding another way. A filter sounds like a much better approach, explicit and unambiguous

IMO there are scenarios where Tag TTL is more useful, such as propagating down a certain number of hops. Plus it would require global metadata for each tag for downstream services to do proper filtering, which may be difficult in open source world.

scenarios where Tag TTL is more useful, such as propagating down a certain number of hops.

do you have concrete use cases in mind? It sounds like an anti-pattern as it assumes whoever sets TTL knows about the organization of the lower levels, breaking the abstraction principle.

How do we move forward with this? Would it help to have a conference call?

Talk a bit with @yurishkuro offline about this:

1. Need to make sure in specs that for the moment we ONLY support TTL(-1) and TTL(0).
2. Every propagation plugin should have an option "decrementTTL" (default true) that allows proxy implementations to set that to false.
3. One possible example for TTL(1) is a "caller" tag, in general on the server side we don't have information who called me (besides ip/port), but in every process we can have a "service_name" tag that is added as a "caller" tag before serialization when we make any RPC/HTTP calls.

Are there any open issues on this?

Talk a bit with @yurishkuro offline about this:

1. Need to make sure in specs that for the moment we ONLY support TTL(-1) and TTL(0).
2. Every propagation plugin should have an option "decrementTTL" (default true) that allows proxy implementations to set that to false.
3. One possible example for TTL(1) is a "caller" tag, in general on the server side we don't have information who called me (besides ip/port), but in every process we can have a "service_name" tag that is added as a "caller" tag before serialization when we make any RPC/HTTP calls.

Are there any open issues on this?

I'll make the change. There are no other open issues.

Why leave out TTL(1)? I think it makes as much sense as -1 and 0, I assume confusion starts as you get to TTL(>1), which I too am not sure of the use case for, so I am glad to see it is being restricted for a starting point.

@tsloughter Because that implies we need to modify our current binary/http format to serialize this information. I am not saying is not useful but we would prefer to add that in the next stage. Does it make sense? I think we can do that later, happy to start a discussion about that but we want to make progress for the moment for the local/global scopes.

@bogdandrutu ah ok, so in order to keep the same format as the "scope" form? Makes sense.

@tsloughter correct, but we rename that to a more generic name that will allow us in the future to open this for a more generic purpose without having to do deprecation etc.

@bogdandrutu can I merge this now?