An alternative proposal on implementing randomness by updating level … #480
Conversation
|
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 |
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. |
|
|
||
| If the `trace-id` value is invalid (for example if it contains non-allowed characters or all zeros), vendors MUST ignore the `traceparent`. | ||
| For the interoperability between vendors, the 6 right most bytes of `trace-id` SHOULD be generated using random or pseudo-random number generation algorithm. If [[!RFC4122]] is used, only the <a data-cite='!RFC4122##section-4.4'>Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers</a> can be used for `trace-id` value generation to satisfy the randomness requirement. |
There was a problem hiding this comment.
only the Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers can be used for
trace-idvalue generation to satisfy the randomness requirement
This is a weird way to word this. It sounds like a requirement, but starts by saying "If RFC4122 is used" which makes it optional? It also doesn't use the SHOULD/MUST language typically used for normative requirements. I would suggest something along the lines of "the trace ID SHOULD be generated using Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers" or similar
|
@SergeyKanzhelev should this be closed? |
|
Closing this PR which has been superseded by the flag introduced in the Level 2 spec. |
…1 spec
I wanted to draft this to propose it as an alternative to the #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
SHOULDmakes 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