►
From YouTube: OpenTracing Monthly Meeting - 2018-03-02
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
A
Please
write
down
in
the
agenda
document
if
you're
in
attendance,
so
we
have
an
attendee
list
and
for
the
agenda
today.
I
have
two
items
that
I
think
are
really
important.
One
is
a
proposal
to
add
the
trace
parent,
headers
header
values
to
as
accessors
to
the
span,
contact
object
in
open
tracing
and
the
other
is
a
proposal
for
more
formal
RFC
process
for
versioning
the
open,
tracing,
api's
and
specification.
A
B
So
we
want
to
enable
all
the
scenarios,
when
you
have
different
components
and
different
ownership
of
these
components,
to
to
correlate
celebrity
across
them.
So,
in
order
to
do
that,
you
need
to
have
a
standard
and
we
thought
what
what
the
place
would
be
for
the
standards
and
tt
seems
to
be
the
right
place
for
it
to
be
mr.
Garza,
who
supported
like
basically,
all
beaker.
We
understand
clusion,
like
our
clouds,
I
called
all
three
clouds
supported
this
idea
and
we
built
is
double
three
standard.
B
So
main
idea
here
is
not
to
make
a
standards
that
everybody
can
use
so
like
generic,
so
generic
that
everybody
can
squeeze
whatever
they
want
into
that,
but
be
a
little
more
specific.
What
a
scenario
you
want
to
achieve
and
like
it
feels
like
every
everybody
will
need
to
do
effort
to
migrate
to
this
standard,
so
some
people
need
to
shrink
their
energies.
Some
people
need
to
like
compromise
on
the
size
of
this
header,
so,
like
all
sort
of
compromise,
that
needs
to
be
done,
but
the
idea
is
like
again
to
you.
B
If
you
want
to
satisfy,
if
you
want
to
comply
to
this
header,
you
need
to
you
need
to
do
something.
So
it's
it's
a
little
bit
more
priests
creatures
and
it's
it's
not
meant
to
be
a
place
for,
like
it's
all
kind
of
header
or
you
can
put
whatever
you
want
so
yeah.
This
is
a
context,
and
right
now
we
are
in
community
group
in
double
3xi.
It
means
that,
like
it
is
out
of
this
community
group
is
just
the
basic
recommendation.
B
C
C
Don't
you
know,
have
128-bit
values
that
that's
so
I'm
gonna
be
at
the
mercy
of
whoever
is
providing
me,
this
parent
header
and
if
I'm,
trying
to
provide
a
feature
like
hey
use,
this
ID
for
logging
in
and
then
you
can
go
and
search
in
your
elk
or
spunk
or
whatever,
for
this
chase.
Id
I'm
now
going
to
be
giving
people
this
access
ur
for
a
trace
idea
that
I
didn't
prepare
or
create.
But
you
know
if
I'm
accepting
a
trace
parent
from
an
upstream
service.
C
Else's
choice
about
how
tracing
IDs
are
formed,
in
this
case,
128-bit
hex,
arrays,
right
and
basic
tracer,
for
example,
uses
64
bit
arrays
64
bit
in
an
integer,
so
basic
tracers
IDs
aren't
on
joint
bit
strings.
So
if
I
were
trying
to
say,
hey
the
trace
ID
for
my
company's
tracing
system
is
this
value,
but
actually
the
the
accessor
that
they
get
access
to?
Is
this
value
chosen
by
some
other
vendor
because
it
came
in
the
trace
parent
I'm
kind
of
I'm
not
actually
able
to
give
my
trace
ID?
D
Why
I
made
a
comment
in
the
dark
that
I
think
referring
to
a
trace
parent
is
misleading.
What
we're
really
doing
is
adding
XSS
to
explain
context,
and
that
means
that
you
just
talking
about
your
own
trace
idea.
The
only
relationship
to
the
w3c
trace
parent
is
just
the
fact
that
the
industry
seems
to
be
agreeing
that,
yes,
we
want
trace,
ID
and
span
IDs
concept
to
be
present
on.
Therefore,
that
there's
a
link
there,
but
it's
not
really
that
we
are
we
taking
that
header
and
basically
making
it
available
in
span
context.
A
Yeah
I
I
would
agree
with
that.
The
intention
was
simply
because
we
appear
to
have
industry
alignment
on
exposing
fan,
ID
trace,
ID
and
a
sampling
bit
over
the
wire.
That
and
those
are
things
people
have
been
asking
for
to
expose
and
open
tracing.
So
it
seemed
given
that
there's
convergence
around
this
trait
parent
header,
there
should
be
general
bayan
on
being
able
to
expose
these
accessors
for
those
concepts
on
the
span
context.
A
But
when
I
designed
the
values
that
they
produce
I
chose
a
more
generic
transport
indicating
we
should
be
string,
values
for
the
IDS
or
something
similar,
possibly
multiple,
different
kinds
of
formats.
We
could
access
them,
but
not
to
overfit
to
the
specific
sort
of
16-bit
text.
Id
that
the
trace
parent
header
defined,
so
they
would
be,
would
be
a
looser,
looser
definition.
A
C
A
A
A
So
it's
doubly
not
particularly
useful
to
concentrate
too
much
on
that
that
format
and
also
I,
would
not
expect
people
to
be
using
these
accessors
to
be
doing
kind
of
trades,
header
indexes
or
something
like
that.
I
would
expect
them
use.
The
tracer
inject
calls
to
be
doing
anything
that
was
tracing
related,
but
it's
just
for
other
systems.
A
C
C
C
A
Was
going
to
say
I
would
imagine
your
your
tracer
would
be
the
thing
that
would
be
extracting
that
header,
and
so
it
has
first
pass
at
deciding
what
it
wants
to
do
about
all
of
that
by
the
time
you
haven't
bank
on
text
object
and
can
ask
it
for
its
trace,
ID
and
span
ID.
Your
tracing
systems
already
sorted
out
what
it
was
present
there.
B
B
D
Again,
the
assumption
is
that
both
transparent
and
trace
State
really
represent
a
fair
and
span
in
the
in
the
caller
and
then
once
you're
inside
the
application.
You're
tracing
will
already
read
that
parent
information
and
create
its
own
span
internally
and
that's
what
really
open
tracing
is
gonna
expose
the
span
ID
of
the
current
span.
D
Until
you
create
a
real
span,
then
it
will
get
a
real
tracer
you
as
Panaji
and
so
I.
Think,
like
the
I,
think,
the
main
idea
of
access
is
really.
You
want
to
use
the
current
spans
ID
to
do
anything
like
login
or
observations
and
sign
things,
and
then
it
doesn't
really
matter
what
came
on
the
wire.
It's.
The
only
relation
to
the
wire
format
is
just
the
fact
that
we
all
in
the
industry
agree
that
span
ID
and
trace
idea.
The
thing
that
makes
sense
to
expose.
B
Okay,
yeah
yeah,
sorry
pardon
my
ignorance,
I'm
not
I
may
not
be
that
familiar
with
all
the
details
but
like
if,
if
we
send
application
ID
as
part
of
tray
state,
we'll
be
able
to
get
this
application
ID
and
like
group
ID
or
a
filter
by
it
and
in
SDK
or
I,
wouldn't
be
able
to
access
this
app
ID
I.
Don't.
E
Mean
that's
what
I
would
say
in
general
goal.
Dopant
racing
is
to
try
and
stay
away
from
exposing
wire
format
to
the
end
user.
I.
Think
really,
if
you're
talking
about
some
trace
your
specific
internal
state,
you
probably
honestly,
your
best
bet
would
be
to
do
an
attempted
typecast,
you
know
catch
the
class
cast
exception
or
whatever,
and
then,
once
you
have
your
trace,
your
specific
span
contacts
to
just
access
the
fields
that
you
want
I
mean
that
would
be
the
sort
of
moral
equivalent
of
what
you're
asking
for
in.
A
Would
say,
I
understand
your
desire
Sergei
around
using
those
as
indices
those
values
indices
in
other
systems.
For
the
reasons
kind
of
mentioned
already,
I
didn't
include
anything
like
that
in
this
proposal,
just
trying
to
instead
focus
on
what
we
know
is
really
really
necessary,
which
is
just
the
main
identifier.
A
A
So
that's
why
the
focus
of
this
proposal
is
just
on
those
three
fields:
I
have
some
ideas
for
how
people
could
expose
some
of
those
other
fields
through
baggage.
If
we
didn't
want
to
add
another
interface
but
I
kind
of
wanted
to
leave
that
aside,
because
I
was
concerned,
it
would
be
a
little
more
contentious
if
we
started
getting
into
that
other
stuff.
B
C
F
A
C
A
Mentioned
this
in
the
proposal
that
it's
variable
ink
specifically
to
be
backwards
compatible
with
existing
ID
systems
and
to
also
before
compatible,
because
this
is
a
version
of
this
header,
the
industry
is
saying:
they're
probably
going
to
standardize
on
this,
but
it
could
also
version
again
right.
Even
a
trace.
Parent
header
has
a
version
field
in
it,
which
is
the
other
reason
why
I
don't
want
to
overfit
to
what's
currently
being
proposed
as
an
ID.
B
E
E
You
know
these
three
aspects
of
that
header
should
be
available
in
open
tracing
and
that's
sort
of
the
guarantee
that's
being
made.
It
doesn't
mean
that
if
you're
doing
something
other
than
w3c
that
you
wouldn't
also
be
able
to
provide
your
own
version
of
the
face
ID,
so
that
is
to
say
it's
not
like
attempting
to
conform
precisely
with
scratch.
It
just
goes
to
support
these
key
concepts
that
people
have
asked
for
for
years.
No
yeah
make
sense.
D
A
A
Having
that
bit
exposed
I
know
it's
been
asked
for
repeatedly,
but
it's
not
clear
to
me
what,
as
a
boolean,
what
kind
of
logical
switching
would
secondary
systems
be
expected
to
be
doing
based
on
that
value,
so
I
really
think
that
the
semantic
meaning
for
it
like
why
what
am
I
going
to
do
or
not
do
whether
when
that
thing
is
on
or
off,
it's
not
clear
to
me.
Yeah.
D
I
guess
one
use
case.
I
remember:
people
were
asking
and
saying:
oh
I
want
to
add
a
lot
more
profiling,
but
I
don't
want
to
bother
if
this
black
trace
is
not
being
sampled
right.
So
that
could
be
an
example,
but
again
that
doesn't
match
with,
for
example,
with
double
3c
definition,
because
there
it
says
if
it's
zero,
it
doesn't
mean
that
it's
not
sample
it's
just
like
we're,
not
telling
you
whether
it's
sample
or
not
right.
It's
like
it's
really.
D
B
A
main
idea-
and
we
do
a
lot
of
sampling
and
our
system
Center
we
will
tree
this
flag-
is
like
somebody's
if
somebody
said
it
to
ones
and
yeah
we'll
try
our
best
to
sample
it
to
collect
it.
But
if
it's
zero,
we
still
feel
like
you'll,
be
on
edge
of
making
this
decision.
So
mostly
it's,
and
even
if
it's
one
we
will
try
our
best,
but
we
are
not
guaranteeing
that
it
will
be
corrected.
A
Yeah
and
once
one
nuance,
that
I
think
is
a
bit
different
between
the
wire
protocol
and
an
improv
accessor
for
this
bit
is
part
of
why
I
think
it's
vague
about
whether
you
should
respect
this
in
the
protocol
aspect.
Is
it
can
be
spoofed
right
like
you?
Don't
you
can't
necessarily
trust?
What's
come
over
the
wire,
and
so
you
have
to
use
this
sampling
value
as
an
indication
right.
It
might
be
coming
from
another
system,
it
might
be
fake,
so
it's
it's
kept
partially
vague,
I
know.
A
A
D
E
Yeah
you're,
a
what
you
were
saying
earlier
about
people
using
in
terms
of
open
tracing
access,
runs
phantom
if
they're,
not
talking
of
sampling
in
general,
but
in
terms
of
the
access
runs
band
context.
Perhaps
the
most
important
use
case
is
indeed
for
just
an
optimization
that
you
can
not
do
anything
if
something
is
being
sampled.
This
doesn't
line
up
particularly
well
with
the
w3c
thing,
but
I
almost
wonder
if
it
shouldn't
be
a
sample
bit
if
it
should
instead
be
a.
This
is
not
sampled,
but
it's
more
of
a
like
I
know.
E
Outfit
I
mean
that's,
that's
actually
actionable
from
a
code
standpoint
in
a
way
that
I
think
could
be
pretty
meaningful
in
the
performance
context.
E
G
A
D
Doesn't
mean
that
we
just
like
shell,
was
completely
right.
We
can
still
work
on
it.
I
would
just
prefer
to
move
on
the
sporadic
accessors,
because
that
seems
like
a
very
easy
thing
to
just
roll
out
and
then
give
immediate
benefits
to
people
where
it
was
sampling.
Like
not
everyone
asked
for
it,
and
we
can.
We
can
work
a
bit
longer
make
on
that.
D
A
E
Won't
take
the
bait
on
onerous,
but
I
will
say
that
we've
given
plenty
of
talks
over
the
last
few
years
about
open
tracing
the
in
instrumentation
API
that
can
be
used
for
things
like
Prometheus
and
so
on,
and
those
use
cases
really
don't
need.
It's
stop
time,
which
is
fine
with
me.
I
think
we
just
means
that
you
know
we
have
to
make
sure
the
documentation.
Is
it's
clear
about
whether
or
not
this
these
tracings
manatees
are
sort
of,
like
quote
unquote
required
or
if
it's
ok
to
return
empty
string
or
something
like
that?
E
C
Companies
do
120
fetch
a
city's
today
so
and
for
anyone
to
support,
trace
context
and
have
this
correlation,
though
you'll
need
to
be
able
to
get
a
unique
identifier.
That's
cross
vendor
compatible
Amazon,
for
example.
Also,
isn't
isn't
doing
it
this
way
so
25
I
DS,
so
you
know
I
think
we
could
start
giving
you
these
incompatible,
trace,
IDs
and
then
have
support
for
the
Latrese
context
of
later,
for
example,
like
you're
saying,
with
the
strings
not
having
a
fixed
link.
D
C
The
yeah
and
that's
the
part,
I
mean
certainly
if
you're
trusting
authenticated
API
is
across
vendors,
where
you
can
trust
the
sampling
decision
and
the
trace
ID,
and
you
just
happen
to
be
using
x-ray
in
one
thing
and
some
other
company
in
another,
and
there
was
this
magic
way
that
you
could
be
sure
to
trust
their
IDs.
That
would
be
cool
and
then
you'd
have
this
magic
cross
vendor
reference
values,
but
yeah
in
in
practice.
People
are
gonna
have
to
be
very
careful
about
writing
rules
to
filter
or
use
links.
C
You
know
to
do
the
the
reference
of
it's
not
gonna,
be
a
globally
unique
value
across
all
the
the
components
in
the
distributed
trace
until
you
can
have
that
functionality
at
the
edge
of
your
service,
like
in
some
nginx
configuration
or
service
stuff
right
like
that,
that
part
seems
tricky
to
me
to
promise
that
it's
that
unless,
unless
are
you're
using
the
same
single
vendor,
that's
pretty
much
the
only
way.
It's
gonna
be
that
for
a
long
time,
I
guess
that
could
be
been
more
clear.
A
technician.
A
Yeah
I
can
see
making
it
clear
that
this
is
these
expectations
are
only
expectations
within
the
tracing
system.
You're
talking
to
write
whatever
tracing
system
is
running
in
your
process
and
you're
asking
ish
for
its
fantasy,
and
it's
criticizing
your
expectation
for
you
really
only
a
religious
if
you're
not
asking
it
can
never
for
about
other
systems
if
I
should
be
using
yeah.
B
A
C
A
C
A
Not
it's
not
the
motivation,
the
motivation
for
the
ability
to
add,
fan
and
trace
observers
in
a
sort
of
generic
fashion.
I'm
surprised
to
do
this.
The
lack
of
any
identifiers
really
makes
it
awkward.
You
end
up
with
a
lot
of
machinery,
attractive
factories
around
the
brass.
That's
great
objection,
you
think
basically
cleaner
accesses
your
IDs
in
a
weird
way
and
then
it's
awkward,
but
there's
a
huge
amount
of
value
to
that
was
come
from
being
able
to
correlate
this
information
in
other
systems.
A
A
C
G
A
But
also
I
think
one
thing
to
look
at
though
in
the
spec
is,
it
does
say,
like
you
can
produce
a
trace
ID
and
when
something
asks
you
for
span
ID,
you
can
just
give
back
an
empty
value
and
I,
don't
think
we
can
I,
don't
think
we
can
mystically.
Add
anything
to
the
open
tracing
expects
it
wouldn't
let
you
do
something
like
that.
It
needs
to
be
some
kind
of
backwards
compatibility.
D
A
Practice
I
think
it's
the
kind
of
thing.
That's
not
too,
concerning
like,
if
you're
using
a
tracing
system
that
doesn't
support
this
stuff,
and
then
you
would
like
to
use
stuff
that
wants
it
you're.
Just
like
oh
well,
my
tracing
system
and
this
cool
other
library
don't
work
with
each
other,
but
it's
not
it's
not
like
a
disaster
or
something
that
would
be
unexpected
for
the
developer.
A
A
So
I
feel,
like
my
big
takeaways,
are
to
really
clarify
that
this
is
not
header
specific.
It's
not
specific
to
the
trace
parent,
supporting
explicitly
that
what's
in
the
w3,
spec
is
just
supporting
fields
that
are
similar
to
the
fields
in
that
spec
and
really
emphasize.
This
is
not
for
automatically
allowing
cross
racer
compatibility
or
Interop.
A
A
Great,
so
the
other
thing
I
would
like
people
to
have
a
look
at
and
I,
don't
really
know
if,
if
ten
minutes
is
enough
time
to
have
conversation
about
it
and
also
I
want
to
leave
room
for
anything
else,
anyone
else
wants
to
talk
about,
but
I
did
create
a
pull
request
around
a
more
specific
RFP
RFC
process
for
moving
the
open
tracing
spec
forward.
Where
each
proposal
to
change
the
API,
its
first
drafted
in
a
document
called
an
RFC
that
is
committed
to
the
specification
repo.
A
It
has
several
states
that
moves
screw
from
draft
to
testing,
where
we
then
implement
a
version
of
the
proposal
as
an
API
change
in
a
quorum
of
major
languages,
and
if
that
looks
good,
then
we
mark
the
proposal
as
accepted
and
add
the
language
and
it
directly
to
the
specification
so
I'm
curious,
just
sort
of
hot
aches
from
people
who
have
had
a
chance
to
look
at
that
proposal.
Is
this
something
that
looks
generally
like
the
right
direction
to
them?
A
C
A
Okay,
if
you
haven't
read
it
yet,
I
would
just
ask
please:
please
take
a
look
at
that,
because
I
think
it's
one
I
do
think
we.
We
definitely
need
a
formal
process
for
a
change
right
now.
It's
just
to
cowboy
I
mean
it.
It
has
been
working
because
people
are
nice
and
care
and
they're
trying
hard,
but
it
would
be
I
think
more
open
to
people
outside
of
the
sort
of
smaller
inner
OTS
si
group
when
it
comes
to
making
proposals.
A
So
we've
got
sort
of
the
open
source
staffing
available
to
to
make
decide.
We
wanted
to
add
something
like
span
ID
and
trace
ID
and
then
go
test
and
roll
it
out
in.
You
know
three
to
five
languages
at
the
same
time
and
then
add
it
to
the
spec.
So
I
think
we
have
the
ability
to
make
these
changes
faster
and
more
coordinated,
but
we
do
need
some
structure
to
explain
to
everyone
how
we're
going
to
do
it.
I.
H
A
A
D
D
My
my
concern
is
that
if
we
say
Ola
just
wait
till
the
next
like
wait
a
month
and
then
try
to
approve
by
the
month,
we
can
be
in
a
single
situation
like
oh,
no
one
actually
read
it
yeah
so
I
would
I
would
prefer
to
just
like
set
another
timeline,
saying
like
let's,
let's
give
people
a
week
or
two
and
then
call
a
vote
within
two
weeks.
Let's
say
and
and
then
just
close
this.
C
D
A
There's
nothing
terribly
original
in
the
proposal.
I
think
the
thing
for
people
to
think
about
that's
just
a
little,
maybe
unique,
about
open
tracing
and
where
we
can't
just
adopt
some
pre-existing
thing
entirely
off
the
shelf
is
the
shape
of
what
we're
trying
to
create
is
slightly
different
from
most
projects.
A
D
D
A
D
D
It's
examples
and
I
mean,
unfortunately,
when
I
was
doing
instrumentation
with
tornado.
You
kind
of
you
want
to
write
your
instrumentation
in
a
completely
a
framework
agnostic
way,
but
at
least
we'll
turn
a
that
you
do
have
to
use
this
special
context.
Manager
called
specs
that
context
without
it
nothing
works
really
as
far
as
a
propagation
and
I
don't
know
what
what
other
frameworks
are
doing.
That's
why
I
was
kind
of
curious
because
simply
just
scaling
thread-local
span,
sorry
scope
manager
doesn't
work,
for
it
is
for
tornado.
G
The
examples
because
I
just
kind
of
porting
them
from
Java,
so
I
will
probably
have
a
comment
later
today,
but
some
of
the
examples
to
use
it.
So,
regarding
the
other
frameworks,
both
money
from
dated
off
and
me-
we
have
been
looking
into
a
similar
approach
rather
like
the
chair.
Ben
is
in.
Are
you
pretty
much
and
basically,
what
they
provide
is
some
kind
of
treads
local
alike.
G
Storage,
where
you
can
have
different
storage
for
each
core
routine,
but
there
is
no,
there
is
no
automatic
propagation.
So
in
that
case
you
basically
what
you
end
up
doing
eventually,
is
that
you
provide
a
specific
stock
manager
for
each
one,
and
then
you
also
have
to
include
some
help
in
fusion
or
or
really
matching
the
library.
So
we
so
this
component
of
end
up
collaborating
with
dispatching
code.
So
you
can
have
this
propagation
that
turtle
has
out
of
the
box
so
yeah.
G
So
it's
well
and
as
I
said,
of
course,
he
actually
part
of
doing
this.
For
those
of
you
who
know
of
doing
the
release
candidate,
one
for
the
new
API
annotation
to
the
technically
was
to
bring
more
ants
project
so
yeah.
If
somebody
has
more
experience
with
me,
specifically
with
AC
value,
1
and
G
event,
that
would
be
great,
so
I
don't
know
it.
D
The
question
is
is
really
whether
the
API
itself
is
is
reusable,
for
example,
like
you
might
be
using
icing
framework
like
event
loop
framework,
but
you
may
also
use
some
standard,
like
some
people
do
that,
let's
say:
URL
live
the
instrumentation
and
we
typically
monkey
patch
that
and
when
you
monkey
patch
it
you,
you
want
to
get
your
context
or
like
the
the
scope
from
somewhere,
and
you
don't
really
know
what
kind
of
scope
manager
you
using
at
this
point.
So
the
instrumentation
has
to
have
some
sort
of
unified
way
of
saying.
D
G
Based
on
what
you
told
me
anything
in
the
Python
examples,
I'm
going
to
start
writing
a
summary
of
what
are
the
exact
implementation
differences
or
you
know,
like
expectation
of
each
manager.
So
we
can
get
a
better
idea
and
some
of
just
showing
examples
around
four-ish
which
framework
okay,
I,
have.
C
A
question
that
only
take
one
minute:
it's
on
the
agenda
I
was
trying
to
make
trace
context,
implementation
for
basic
tracer
for
go
and
I
was
talking
with
Sergey
about
it
and
understanding
the
the
the
draft
he
updated
and
and
alloys
updated,
but
I
granted
to
just
parsing
was
fine.
Person
was
easy,
but
then
I
got
to
the
place
where
I
realized
I
needed
to
use,
decide
whether
to
change
the
tracer
to
use
64-bit
currently
use
a
64-bit
Rossetti's,
and
do
you
think
it
should
be
changed
to
use
128-bit
trace
IDs?
C
Or
should
it
be
done
in
this?
In
this
pattern,
where
we
discussed
in
Seattle,
you
could
put
custom
vendor
stuff
in
trace
state,
and
then
you
know
a
lot
of
the
128-bit
trace
ID
to
be
stored
in
some
kind
of
spam
context,
place
and
and
then
spit
out
when
you
propagate
out
again
later,
but
internally,
you're
still
using
a
64-bit
trace,
ID
inside
of
the
tracer
itself,
and
whether
that
the
complexity
of
that
was
worth
keeping
like
the
protobuf
wire
protocol.
C
C
A
Think
I
haven't
done
an
audit
of
the
basic
tracers,
but
it
sounds
like
when
it
comes
to
taking
a
wire
protocol
that
they
use
and
header
types
and
stuff.
It
would
be
great
if
we
picked
something
across
languages
that
we
intended
all
the
basic
races
to
converge
on
I'm,
not
sure
if
they're
even
compatible
with
each
other.
At
the
moment,
they're
sort
of
just
started,
as
example,
code
right
I,
never.
A
C
Other
no
pythons
in
64,
just
like
current
go,
is
yeah
I
mean
but
yeah.
That
just
opens
a
question
for
then
to
demonstrate
compatibility
with
receiving
a
trace
parent,
that's
128-bit!
You
need
to
put
that
128-bit
indentify
somewhere
and
then
spit
it
out
on
your
right,
and
is
it
worth
doing
all
that
and
doing
like
that
custom
vendor
thing,
or
is
it
worth
just
changing
all
the
basic
racers
do
128-bit
IDs
either
one
you
know
one's
an
interesting
demonstration
of
the
anything
you
know
where
hey
this,
this
tracer
doesn't
support.
G
C
A
A
A
My
suggestion-
and
it's
just
the
suggestion-
is
that
well
in
general,
I
think
we
need
to
revisit
the
basic
racers
and
decide
what
their
purpose
in
life
is
for,
but
independent
of
that
I
do
like
the
emphasis
on
basic
and
I,
like
the
idea
that
there's
simple
code
that
you
can
read
that
does
the
canonical
whatever
the
current
test
standard
is
right.
So
having
them
by
default
in
a
very
basic
manners,
support
128
says
you
know,
IDs
sort
of
doing
everything
tonics
for
x-ray.
C
A
C
A
So
that
would
be
my
suggestion
is
just
that
they
say
they
are
canonical.
They
think
they
match
whatever
the
Christmas
w3t
effect
on
headers,
and
it
would
be
then
I
agree
interesting
experience
if
there's
a
way
to
add
some
optional,
you
know
or
plugins,
or
something
that
allows
you
eat
some
switchover
with
this
header
or
with
these
IDs.
That
turns
out
to
be
a
useful
thing
to
explain
to
people,
but
it
seems
a
little
secondary.
A
D
Know
I
would
suggest,
starting
with
like
what
they
call
level
1
or
you
you,
except
in
crime
and
trace
ID,
but
you
not
use
it
as
your
own.
You
just
store
it
as
a
as
a
tag
somewhere,
because
then
you
don't
have
to
change
all
the
way
cick
traces
all
at
once.
You
can.
You
can,
and
you
already
have
like
some
compatibility
with
a
spec
and
then
the
next
phase
could
be
okay.
G
A
A
But
then
there's
also
people
would
like
some
basic
thing
that
that
handled
the
wire
protocol
propagation
for
them
and
then
they
you
know,
can
then
just
write
some
little
plug-in
to
spit
out
the
span,
information
somewhere
and
there's
backwards,
compatibility
or
no
backwards
compatibility,
there's
just
a
bunch
of
questions
around
them
and
like
what
their
point
is.
I
think
we
should
clarify
that
at
some
point,
especially
if
we're
going
to
be
changing
them.
C
A
A
Lights
apart
are
tracers,
at
least
in
some
languages,
to
even
reference
a
basic
picture
like
how
easy
we
are
at
Python,
but
that's
again
like
I,
would
say
if
the
basic
rates
have
changed
so
then
we
would
just
clone
the
code
we
wanted
and
like
life
would
move
on
like
we
would
be
fine.
I
just
don't
know
what
people's
expectations
are
around
them.
I
think.