An alternative proposal on implementing randomness by updating level …

[SergeyKanzhelev]

…1 spec

I wanted to draft this to propose it as an alternative to the https://github.com/w3c/trace-context/pull/474. As discussed before, spec already had all suggestions to generate randomness and keep it as right most characters. Clarification to the already existing language and keeping it as SHOULD makes it compatible to the existing version. Also, most of implementations are already setting random bytes and will be compatible.

I'd suggest we review and consider this as an alternative to the flag-based proposal. It eliminates the fragmentation of implementations. All OpenTelemetry implementations will work fine out of the box.

As for the issue of implementations that do not generate randomness (on purpose or due to an error), this proposal may be cleaner as it eliminates situations when the flag is set and implementation is still not providing randomness.

---

Preview | Diff

[yurishkuro]

I don't think this is an alternative to #474. Existing spec uses SHOULD for randomness, which means randomness is not mandatory and cannot be relied upon. Introducing randomness bit makes it into a guarantee.

[SergeyKanzhelev]

I don't think this is an alternative to #474. Existing spec uses SHOULD for randomness, which means randomness is not mandatory and cannot be relied upon. Introducing randomness bit makes it into a guarantee.

I understand the motivation. It makes sense from engineering perspective. My point here is that most implementations are already compliant (do we know of any non-compliant?), and with introducing the bit, we will need to deal with the implementations that don't see a value in setting the bit, but random anyway and implementations that claim to provide randomness, but fail to do so (maliciously or by mistake). Since SHOULD carries a lot of weight in specs, this gives a good enough alternative from my point of view.

So again. I agree with the bit from the pure engineering perspective. From organizational perspective, assuming errors and misread of a spec, asking the "default implementation" to carry this randomness may give us more value.

Also, as you may see, we never required the trace-id to be random in spec, but nevertheless heavily rely on it. This proposal basically doing the same with randomness.

[yurishkuro]

we never required the trace-id to be random in spec, but nevertheless heavily rely on it

I don't believe any part of the spec relies on randomness. The only relevant requirement is uniqueness (even that is best effort). We use SHOULD because there are users who have legitimate reasons to use 3rd-party IDs as trace IDs (this request came up many times in Jaeger SDK repos), for which randomness cannot be guaranteed.

[SergeyKanzhelev]

we never required the trace-id to be random in spec, but nevertheless heavily rely on it

I don't believe any part of the spec relies on randomness. The only relevant requirement is uniqueness (even that is best effort). We use SHOULD because there are users who have legitimate reasons to use 3rd-party IDs as trace IDs (this request came up many times in Jaeger SDK repos), for which randomness cannot be guaranteed.

I understand this. This is exact reason for SHOULD. However, given a choice whether to set randomness flag or now, specification by itself doesn't give any incentive to set it. Even if ID is generated as random. This may lead to fragmentation of trace-ids and make situation even worse.

Maybe there is a middle ground where this clarification is needed, but also a flag is introduced.

[bogdandrutu]

@SergeyKanzhelev should this be closed?

[kalyanaj]

Closing this PR which has been superseded by the flag introduced in the Level 2 spec.