►
From YouTube: 2023-03-21 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
B
C
B
C
B
I
see
thank
you
for
the
clarification,
okay,
yeah.
Let's
quickly
then
talk
about
my
stuff
and
then
yeah,
let's
switch
to
your
to
your
own
points.
Okay,
thank
you!
So
much
yeah,
the
first
one
is
just
a
request
for
reviews.
I
mentioned
these
PR
from
Christian
Noy
Mueller.
Basically,
it's
just
clarification
that
when
you
you
are,
you
are
getting
down
the
SDK
pipeline.
You
you
can
get
the
full
context,
but
you
don't
have
to
you
can
just
get
get
your
spam
context.
The
pattern
is
one
context.
B
B
B
B
The
the
second
option
is
about
adding
an
optional
Tracer
recording
operation
that
would
record
links
as
events,
which
is
good.
Although
there's
a
problem
about
the
like
mixing
link
representations,
you
know
in
two
different
forms
and
even
though
we
have
had
some
initial
discussion
about
potentially
deprecating
links
and
making
them
events
all
the
way
we
we
would
still
need
to
have
that
discussion.
That
may
be
a
long
discussion
and
I.
Don't
know
we.
We
don't
know
for
sure
whether
the
the
answer
will
be.
B
Yes,
let's
go
with
events,
so
that's
the
bigger
problem
there
you
know
the
last
one
is
about
adding
link
a
sub
either
spam
operation
for
languages
that
are
fine,
adding
operations
to
interfaces
or
just
adding
the
other
side,
some
extra
or
I
don't
know
how
to
call
it
operation,
module
level
operation
these
good.
Why?
If
we
make
sure
that
this
works
nicely,
then
we
would
be
free
to
have
more
operations.
So
basically
those
are
the
things
yeah
I,
don't
know
whether
we
have
opinions
here.
D
B
D
Right
no
I
mean
in
terms
of
breaking
interfaces
right
like
in
terms
of
go
the
ways
it
would
break.
Interfaces
are
ways
that
we
say
are
fine
right.
If
you've
implemented
that
we
we
have
a.
We
have
a
policy
that
says
if
you're
going
to
implement
the
open
Telemetry
interfaces,
you
have
to
keep
up
with
interface
changes
and
provide
a
new
implementation.
D
E
G
Yes,
I
think
that's
my
concern,
too,
is
having
languages
that
have
abstract
classes,
have
a
default.
No
op
implementation
means
you
end
up
with
silently
wrong.
Behavior
from
the
end
user's
perspective
right
because
they
expect
a
link
to
be
added,
but
they're
they're,
not
using
the
implementation
that
actually
adds
links.
So
they
call
it
and
nothing
happens.
D
F
C
The
other
thing
is:
there's
two:
two
types
of
compatibility
forwards
and
backwards:
okay,
forwards
would
be
if
I'm,
using
the
current
API
with
a
newer
SDK,
doesn't
work
well,
I,
don't
have
access
to
or
sorry
yeah
that's
actually
backwards.
Sorry,
if
I'm
using
the
newer
SDK
with
older
API
right,
then
I
don't
have
that
ad
link
method,
so
everything's
gravy,
but
we
actually
don't
guarantee
forwards.
Compatibility
which
would
be
someone
has
a
new
API
with
an
older
SDK.
C
H
G
G
They've
still
got
the
method
on
the
interface
that
they
could
call
and
go
they're
going
to
end
up
either
with
a
population
failure,
because
now
their
SDK
implementation
doesn't
satisfy
the
interface
in
the
API
or
if
we
go
through
some
hoops,
they
end
up
with
silent
failure
because
of
no
Ops
or
they
end
up
with
panics
because
of
embedded
interfaces.
But.
H
Yeah
I
I
disagree
with
I,
don't
think
a
compilation
error
is
acceptable,
but
I.
Think
a
no-op
is
not
a
failure,
as
Bogdan
says
in
the
comments
yeah
it.
You
know
it's
perfectly
reasonable
for
a
library
with
Native
instrumentation
to
have
a
a
higher
dependency
or
a
dependency
on
a
higher
version
of
the
API
than
the
user's
application
does,
and
in
that
case,
if
they're
using
instrumentation
apis
that
don't
yet
exist
on
the
SDK.
That
information
should
just
get
dropped
on
the
ground.
D
D
That's
at
least
the
main
reason
why
we've
said
these
kinds
of
changes
should
be
a
minor
version
bump
and
that's
usually
the
issue
that
comes
up
and
go
I'm,
not
sure
about
C
plus
plus.
So
my
presumption
is
like
that's
the
actual
blocker,
not
not
these
issues
in
Java
and
other
languages,
where
it's
more
of
a
question
of
which
is
preferable
right
in
go
like
it's.
D
D
I
I
D
C
No
it
you
can
do
this
in
a
way
that
won't
break
C,
plus
plus,
like
we,
we
talked
about
it
in
chat
like
there's
at
a
at
a
bare
minimum.
You
can
create
a
second
interface
that
has
this
method,
and
then
you
return
something
and
implements
both
and
then,
if
somebody
is
using
the
previous
interface
right,
you
still
have
something:
that's
conformant
that
can
pass
it's
binary
compatible.
So
it's
not
actually
it's.
This
is
a
non-issue
in
C
plus
plus,
so
it
apparently
it's
just
an
issue
of
go
even
though
I
I
don't
know.
C
Thing
that
they,
the
thing
that
you
provide,
is
always
going
to
be
span
2
or
whatever.
The
new
version
of
the
span
is,
however,
existing
instrumentation
because
of
the
way
C
plus
plus
does
interface
conformance,
will
always
give
you
that
same
original
interface.
You
had
with
span
no
matter
what,
unless
you
recompile
your
code
and
say:
okay
now,
I
want
to
use
that
new
span.
That
has
the
new
thing.
It's
basically
a
way
that
you
can
do
extensions
in
C,
plus,
plus
yeah.
J
K
J
J
J
H
Quick
comment
on
the
event
piece:
I
I,
don't
have
a
strong
opinion
about
this
particular
conversation,
but
I
find
it
strange
that
metrics
and
logs
have
a
data
model
document
and
traces.
Don't
we
don't
have
a
good
description
of
what
an
event
is
versus
a
link
is
and
I
think
that
kind
of
is
hurting
this
conversation,
because
you
know
it's
not
completely
clear
whether
this
is
absolutely
needs
to
be
a
link
or
an
event.
B
Yeah
and
I
think
that
that
would
be
one
of
the
problems
that
we
would
have
to
have
that
discussion
Define
that
model
and
then
have
a
discussion
on
the
final
decision.
You
know
and
I,
don't
know
whether
this
is
something
we're
going
to
do
right
now.
Maybe
we
should
what
I
guess
that
my
point
is
that
as
the
German
dimension
in
the
chat,
we
also
need
to
think
about
adding
new
stuff
anyway,.
J
That's
how
I
remember
this
conversation
ending
last
time
we
had
it
in
the
spec
meeting.
Was
we
needed
to
have
a
better
definition
of
the
data
model
here
before
we
move
forward,
because
I
think
that
was
like
the
big
issue
also
is
when
we
moved
to
Carlos
I
think
it
was
your
PR
saying
that
we
do
this
via
at
an
event.
First,
objection
was
that,
like
this
doesn't
match
the
data
model
and
it's
like:
well,
we
actually
don't
have
a
data
model
and
I
think
that
was
like
the
big
problem
there
right.
D
But
I
want
to
be
clear:
I
object
to
adding
this
as
an
event,
because
it's
just
not
clean
API
design.
That's
what
I
call
the
the
found
art
approach
to
design
where
it's
like.
Well,
we
just
happen
to
have
this
other
thing
over
here,
that's
kind
of
flexible,
so
why
don't
we
just
shoehorn?
This
thing
in,
like
it's
very
clear
that
links
aren't,
depends
right,
like
we.
D
It
we
it's
super
clear
from
the
description
that
events
are
logs.
A
link
is
not
a
log
and
you
could
maybe
our
API
has
a
flexible
enough
interface
in
some
languages.
You
could,
you
could
literally
shoot
hornet
in,
but
it's
it's
certainly.
We've
made
a
distinction
between
links
and
events,
so
my
point
is:
even
if
we
wrote
this
down
in
a
data
model,
it
would
come
down
that
these
are
two
separate
things
just
to
be
clear
in
this
particular
use
case.
Yeah.
J
So
I
also
Ted
I.
Think
to
your
point,
I
hear
you
like
I
I,
agree
like,
but
I
also
I
didn't
see
it
necessarily
as
as
a
situation
where
we
are
just
shoehorning
it
in
like
I
I.
That's
not
a
great
approach
just
to
shoot
or
something
that's
open.
You
know
put
in
there
like
I
I,
hear
you,
but
I
mean
when
the
problem
was
described
originally
in
the
original
PR.
D
That's
why
I
wanted
to
explore?
Okay,
but
I
think
the
it
feels
to
me
like
the
the
core
thing
here.
Is
we,
as
a
community
I,
think
we
do
a
very
good
job
of
not
frivolously
or
indiscriminately
touching
our
stable
interfaces
like
we
do
a
good
job
of
being
really
thoughtful
about
adding
things,
but
there's
a
line
between
that
and
whether
or
not
like,
we
can
actually
add
a
method
to
our
existing
interfaces
and
what
we
have
before
us
is
something
that
if
we've
said
we
are
allowed
to
do
this
when
we
need
to.
D
We
have
a
case
where
it
feels
to
me
like
the
clear
obvious
answer
that
would
be
the
most
discoverable
to
end
users
and
makes
the
most
sense
it's
just
an
ad
link
operation
that
the
only
reason
we're
exploring
these
other
things
is
because
we're
unsure
of
whether
or
not
we're
allowed
to
to
add
a
method
to
our
interfaces.
So
that's
that
to
me
feels
like
the
core,
like
the
Crux
of
it.
J
Yeah
I
so
I
mean
I,
think
that
I
hear
you,
but
I
also
think
that
we
exist
kind
of
in
a
gray
area.
You
know
and
I
know
you
work
really
well
in
Gray
areas.
Ted
so
you'll
probably
understand
this,
but
it's
just
like
you
know,
like
I
I
agree
like
I,
don't
want
to
say
that
you
know
goes
coming
to
this
community
saying
that
you
can't
extend
interfaces
like
that.
We
agree.
You
know
at
the
onset
that
we
were
going
to
be
able
to
do
this.
We
have
it
in
our
code.
J
We
definitely
have
complaints
from
users
that
we,
you
know
say
we're
gonna.
Do
this
like,
like
it's
very
clearly
something
that
we've
said
that
we
want
to
do.
I
just
think
that
there
needs
to
be
some
sort
of
cost
analysis
on
on
adding
this,
because,
if
you
know
like
you
said
like
the
obvious
answer,
is
an
ad
link
to
the
spam,
that's
great,
but
if
you
can
get
like
99
of
the
way
there
with
something
else
like
you
know,
is
it
really
that
much
of
a
burden
to
say
like?
J
K
I
have
a
proposal
to
tell
your
question,
so
do
you
think
it
makes
sense
for
the
spec
to
move
forward
and
add
new
apis
I,
as
we
see
General
need
across
the
languages
and
the
goal
and
maintenance
can
decide
when
to
take
a
small
batch
of
apis
and
and
handle
some
breaking
changes
for
from
gold
perspective,
for
example,
if
you
think
ad
link
would
be
something
that
worries
the
gold
users,
then
don't
do
it
right
now
and
maybe
a
year
later
you
have
four
apis.
That
makes
good
justification.
Then
you
do
it
in
a
batch.
I
So
I
I
was
just
writing
this
to
Tyler
I
think
if
they
do
the
same
trick
as
I
propose
for
metrics
to
use
the
abstract
classes.
If
they
do
it
once
now,
then
they
can
add
later
how
many
methods
they
want.
So
if
we,
if
they
are
concerned
that
breaking
once
is
a
breaking
change,
they
can
break
in
a
way
that
it
makes
it
extensible
in
the
future.
J
J
K
J
Yeah
I
I,
hear
you
Riley
and
like
it
helps
like
batch.
The
pain,
I
guess
is
what
you
could
say,
but
I
also
think
about
it
from
the
instrumentation
side
and
I'm
like
hesitant
to
not
try
to
keep
up
with
the
specification.
You
know
if
you
have
all
these
other
languages
that
are
able
to
link
things
and
goes
the
only
one
they
can't.
K
J
Yeah
yeah
I
mean
like
usually
that's
you
know.
Some
sort
of
V2
is
is
how
the
goat
Community
would
talk
about
that
as
like
the
batch
changes
going
there,
but,
as
Ted
pointed
out
like
that's
a
really
big
problem,
because
then
all
of
the
instrumenters
then
have
to
make
this
upgrade
and
anything
that
doesn't
do
anything
like
you
know,
upgrades
to
the
instrumentation
doesn't
actually
get
those
those
new
methods
or
listen
to
functionality.
D
I
programmed
go
for
many
years,
so
I'm
I'm,
familiar
with
the
community
and
the
arguments,
but
it
feels
like
it's
a
bit
of
a
tempest
in
a
teapot
right
like
like
it's
more
breaking
the
letter
of
the
law
and
go
and
in
in
practice,
is
not
isn't
actually
a
problem
for
our
end
users.
To
add
this
as
an
interface
like
that's,
we
we
I've,
we
have
gone
around
and
around
this
particular
track
and
go
like
many
times,
and
we
always
end
up
back
at
this.
D
D
Right
and-
and
we
don't
want
to
be
in
a
case
where
it's
it's
true-
it's
you
know
if,
if
you
want
to
put
a
bit
of
padding
in
there
so
between
so
people,
aren't
getting
a
compilation,
error,
they're,
getting
a
warning-
that's
that's!
Okay,
but
I
do
think
it.
It
really
is
the
responsibility
of
implementers
to
keep
up
with
interface
changes,
because
the
Telemetry
they're
getting
out
of
their
system
is
in
fact
incorrect.
B
By
the
way,
I
would
like
to
time
box
this
discussion.
We
have
been
talking
about
half
an
hour
and
it
has
been
great
but
I
think
Josh
has
a
lot
of
stuff
in
his
plate.
So
let's
keep
talking
offline,
Tyler
Anthony
about
our
options
there
yeah.
Thank
you
so
much
for
the
discussion.
If
that
makes
sense,.
C
J
C
G
Mean
no
I
think
if,
if
we're
going
to
do
anything,
we
go
forward
breaking
the
interfaces.
If
adding
a
new
method
is
what
the
spec
says,
we
have
to
do.
That's
what
we're
going
to
do.
I
I
would
like
us
to
consider
the
other
options,
but
if
everything
has
been
rejected
and
the
specs
says,
adding
the
new
method
to
this
interface
is
the
only
acceptable.
C
G
J
B
D
C
C
This
one
is
just
a
call
for
people
to
kind
of
check
the
the
discussions
Mark
discussions
as
resolved
if
they
are
resolved-
or
you
know
we're
looking
for-
we
actually
do
have
enough
approvers
on
that,
but
looking
for
more
kind
of
consensus
overall
on
that
sucker.
So
there's
a
there's
been
a
lot
of
discussion
on
that
I
think
it's
a
good
discussion.
This
is
basically
just
trying
to
say
what
is
in
scope
for
semantic
conventions
and
what
is
out
of
scope
in
the
specification.
C
All
right
next
bit
is
a
little
more
intense.
So
we
have
a
question
around
schemas
and
schema
URL
and
there's
an
open
issue
about.
Can
we
rely
on
schema
URL
for
stability
right?
There
are
concerns
around
schema,
URL
and
what
happens
as
it
feeds
through
a
collector.
So,
for
example,
I
can
actually
Define
a
set
of
processors
that
would
violate
semantic
conventions
or
somehow
remove
things
that
you
would
expect
that
are
marked
as
required.
That
sort
of
thing,
and
today
that
Telemetry
would
still
have
a
schema
URL
attached
to
it.
C
That
is
now
violated
right.
So
this
is
kind
of
us
trying
to
understand
the
scope
of
semantic
inventions.
The
scopus
give
me
URL,
but
we
are
providing
a
recommendation
from
the
working
group
for
now
for
how
people
should
proceed.
Our
recommendation
is
actually
that
we
remove
the
part
of
the
specification
that
says
you
can
rely
on
schema
URL
as
part
of
stability,
just
because
we
we
actually
don't
think,
there's
enough.
We
have
until
April
before
that
that
Clause
comes
true,
but
we
just
don't
think
there's
enough
weight
in
the
ecosystem.
C
Right
now
for
schema
URL,
we
could
push
the
date
back
as
one
option,
but
we're
recommending
just
to
remove
it
for
now
until
we
actually
have
the
right
mechanisms
in
place.
The
second
thing
that
we're
recommending
is
actually
splitting
the
semantic
convention
version
number
from
the
specification
version
number
we'll
talk
about
that
in
a
second
and
the
third
thing
we're
recommending
is,
we
continue
to
provide
schema
URLs
and
we
provide
them
as
an
optional
kind
of
conversion
utility
that
will
help
you
through
both
minor
and
major
version
bumps
of
semantic
inventions.
C
G
C
C
C
Any
other
concerns
there,
okay,
so
the
big,
the
big
part
of
this
recommendation,
I
think
the
first
piece
is
actually
this
this
here,
where
we
are
planning
to
split
semantic
inventions
from
the
specification
there's
an
Otep.
Please
take
a
look
comment
review
that
sort
of
thing
I
think
this
is
kind
of
the
meat
of
why
and
and
and
there's
a
lot
of
benefits
to
doing
so.
C
C
C
What
this
does
not
mean
is
this
does
not
mean
we're
just
blanket
taking
all
ECS
and
shoving
it
open
Telemetry.
This
does
not
mean
we're
breaking
all
the
existing
semantic.
Dimensions,
though
this
means
we're
going
to
be
evaluating
what
we
have,
what
they
have
and
we're
building
a
new
standard
together
and
that
new
standard
can
is
starting
with
otel
as
the
basis
right
with
with
ECS
coming
in.
C
C
C
Based
on
whether
it's
an
sqs
message
or
an
HTTP
message.
Our
specification
is
designed
to
just
be
arbitrary
kind
of
key
value,
pair
insertion
into
messages
or
into
HTTP
request,
headers,
that
sort
of
thing
and
I
think
there's
a
bit
of
a
mismatch
here.
That
needs
to
get
called
out
for
instrumentation
authors.
N
I
mean
I
had
more
or
less
the
same
question,
but
I
can
say
for
sure
at
least
the
way
that
this
is
handled
in
the
SDK
in
in
the
AWS
SDK
for
JS
instrumentation
is
that
the
instrumentation
itself
directly
calls
the
propagator
instead
of
the
propagation
API,
because
there
was
no
way
for
the
instrumentation
to
select
a
specific
propagator
using
our
existing
API
and
because
there's
nothing
along
those
lines
in
the
spec.
We
didn't
want
to
add
anything
like
that.
M
I
actually
wanted
to
point
out
that
this
is
also
how
it
works
in
the
the
Java
API.
The
Java
instrumentation
was
written
like
this,
a
while
back
by
AWS
Engineers
to
call
the
X-ray
propagation
directly
as
well.
So
if
anything,
this,
this
PR
is
more
of
a
formalization
of
how
it's
being
done
in
individual
instrumentation
repos,
in
order
to
make
it
more
consistent.
L
L
N
To
be
honest,
I'm
a
little
bit
but
I
wonder
if
this
shouldn't,
if
we
should
have
a
specification
specifically
for
an
exception
for
the
AWS
SDK
I,
think
we
might
be
better
off
carving
out
a
more
General
exemption
for
something
along
the
lines
of.
If
the
default
propagation
can't
be
used
for
for
some
instrumentation,
then
it
should
have
the
freedom
to
do
what
it
needs
to
do
in
order
to
work.
I
don't
want
I,
don't
want
to
end
up
in
a
situation
where
we
have
to
specify
every
time
something
like
this
comes
up.
N
C
Yeah
I
want
to
call
out
that
I
think
there's
normative
and
non-normative
pieces
of
the
specification,
and
it
sounds
like
this
is
non-normative
language,
but
it's
kind
of
like
a
guide
or
supplementary
thing.
This
is
why,
in
the
pr
I
recommended
that
we
put
it
under
compatibility
thing,
if
you
want
to
be
compatible
with
AWS
x-ray
propagation,
here's
a
guide
for
how
to
accomplish
that
similar
to
like.
C
If
you
want
to
make
sure
you
know
your
Prometheus
compatible,
here's
how
you
do
that
we
could
have
one
for
other
Cloud
providers
too
I'm
happy
to
have
one
for
Google
so
that
people
understand
how
that
works.
That
doesn't
bother
me,
it's
more
does
this,
you
know
I!
Think
fundamentally,
is
it
normative
in
the
spec
is
a
good
question
right
is?
Is
this
a
should,
or
is
this
a
guide,
and
then
after
we
decide
that
the
second
thing
would
be?
Does
it
belong
in
the
spec
at
all,
right
all
right?
How
about
I
invert?
C
G
N
Yeah
I
think
Tyler's
point
that
do
we
want
every
language
to
relearn
AWS?
It's
not
it's,
not
every
language.
It's
only
people,
it's
whoever
is
writing
instrumentation
for
AWS
and
everybody
writing
instrumentation,
for
everything
should
take
the
time
to
understand
the
mechanics
of
that
thing
and
the
set
and
I
think
it's
not
unreasonable
at
all.
To
expect
AWS
SDK
instrumentation
authors
to
understand
that
need
yeah,
I,
I'm
I'm,
just
worried
about
constantly
adding
to
compatibility
and
extend
exemptions
in
the
spec
for
individual
things.
M
C
Right,
there's
there's
a
meta
point
that
I
want
to
call
out
that
actually
bothers
me
significantly,
which
is
in
hotel.
We
tell
users,
you
have
this
propagation
format
and
that
propagation
format
is
used
in
order
of
priority
and
right
now,
AWS
cannot
participate
in
that
at
all.
Aws
has
to
be
hard-coded,
it
has
to
be
special
treated
and
I.
Think
that's
problematic
for
users.
C
We
so
in
Google,
we've
actually
provided
a
way
where
you
can
actually
use
the
the
propagators
in
hotel
and
you
can
actually
specify
an
order
and
a
priority,
and
you
can
use
it
to
decide
if
you
want
to
use
a
Google
proprietary
format
or
prefer
the
w2c
trace
context
and
the
way
that
it
works
is
effectively
you'll
use
both,
but
it'll,
work
right
and
I.
Think
I.
Think
the
the
specification
allowed
us
to
do
that
with
how
we
were
working.
C
Amazon,
though,
doesn't
have
that
as
an
option
due
to
some
nuances,
and
that's
actually
the
thing
that
most
disturbs
me
about
this
particular
PR
is
we
have
something
that
that
is
a
context
propagator
that
is
important
to
our
community
right.
If
it
wasn't
important
the
community,
no
one
be
caring,
no
one
would
write
the
instrumentation
and
it
doesn't
fit
with
the
specification
of
how
we
specify
propagated
priorities
with
our
propagator
format.
Today,
to
me,
that's
the
most
important
bit
of
this
and
that's
why
I
think
something
belongs
to
the
specification
to
call
out
hey.
C
This
is
odd
users.
Here's
a
bunch
of
hackery
that
we
have
in
place
that
that
you're
gonna
have
to
deal
with
for
now
and
I
think
we
should
fix
it
over
time
and
find
something
to
resolve
this,
but
like
to
me.
That's
the
fundamental
problem
is
I,
can't
as
a
user
of
Hotel
come
in
and
say
this
propagator
ordering
that
I
specified
in
my
config
is
what's
used
when
it
comes
to
AWS,
it's
all
this
hard-coded
stuff.
L
I
would
like
to
argue
that
actually,
because,
if
Services-
it's
probably
maybe
even
per
service,
at
least
the
measure,
it
can
be
different
if
the
services
support
only
that
format,
it
makes
no
sense
to
put
Trace
context
there,
at
least
for
now
right,
even
though
I
per
we
do.
Even
if
service
doesn't
support
it
yet,
but
essentially
the
instrumentation
of
specific
service
knows
what's
formatted
supports
and
it
can
make
decisions
right
and
if
it
uses
something
that
user
provided,
the
user
does
not
know.
Usually.
L
G
I
think
more
generally,
instrumentation
should
use
the
propagation
that's
provided
by
the
the
user
or
the
application
operator
unless
the
instrumentation
knows
that
there
is
no
way
that
that
can
function
or
that
there
is
only
one
propagation
format
that
can
work.
The
key
here
AWS
is
the
communicating
party,
not
some
other
service
that
you
are
in
control
of.
G
If
you're
in
control
of
the
Service
choose
whatever
propagation
format
you
want,
but
one
of
your
parties,
your
counterparty,
has
chosen
the
format
that
has
to
be
used
here,
and
that
is
true,
whether
it's
AWS
or
whether
it's
anybody
else
right.
If
you're
communicating
with
a
party
that
uses
one
single
propagation
format,
you
have
to
use
that,
no
matter
what
you
want
to
use
elsewhere,.
C
Okay,
so
we're
at
our
time
box,
sadly,
which
I
expected
to
happen
so
I'm
going
to
say
two
things
going
forward.
One
is,
it
sounds
like
there
needs
to
be
some
general
purpose
thing
in
the
spec
to
handle
this
kind
of
a
like.
We
should
probably
update
language
or
something
to
make
it
apparent
that
like
this
is
how
we
want
to
handle
these
special
cases
like
the
what
ludmill
is
saying,
what
Anthony
is
saying
what
Daniel's
saying
like?
C
We
need
a
way
to
be
able
to
specify
that
the
propagation
format
the
user
provides
can
be
overridden
and
should
be
in
a
scenario
where
there's
no
viable
other
propagation
format,
and
this
is
the
only
viable
way
to
propagate
Trace
ID
you're
allowed
to
deviate
and
use
that
I.
Think
that
means
a
call
out
in
the
spec
second
thing:
I
want
to
I
want
to
ask,
and
we
will
take
this
offline
right
is.
C
Should
we
have
non-normative
language
for
guidance
on
how
to
do
instrumentation
somewhere
for
these
cross-language
six,
so
people
can
find
it
and
Discover
it
and
not
have
to
relearn
from
scratch.
Does
that
is?
Is
that
a
piece
of
open
Telemetry
that
belongs
somewhere,
maybe
not
in
the
spec,
but
does
it
belong
somewhere?
Where
should
we
put
it?
I
want
to
open
that
question
to
everybody
we'll
follow
up
on
that
next
week,
sound
good
lidmilla.
Do
you
want
to
start
raise
your
final
issue
here,
yeah.
L
My
question
on
this
was
in
database
conventions.
We
don't
really
provide
anything
except
very
common
things
like
radius,
MySQL
and
a
few
others.
The
cosmos
DB
is
vendor
specific
and
also
specific
technology.
Should
we
move
it
out
of
database
semantic
conventions
and
then
to
instrumentation
like
where
Dynamic
DB
exists,
or
if,
if
it's
okay,
to
put
it
as
an
extension
to
the
general
database
conventions,
could
people
take
a
look
and
raise
any
concerns.
C
All
right,
I
think
I,
guess
what
I
want
to
ask
of
the
two
A's
two
AIS
I
have
on
number
one
of
the
specification.
Hook
is
there
consensus
that
that
is
the
right
thing
to
do
to
put
a
hook
that
allows
instrumentation
to
hard
code
specific
propagation
and
that
we
make
it
clear
to
Hotel
users
that
this
happens?
That
instrumentation
will
do
this,
and
instrumentation
can
be
clever
in
that
fashion.
Does
that
make
sense
to
do.
C
G
C
This
is
important
to
me
around
instrumentation
author
guidance,
so
once
again
can
help
another.
So
this
is
I.
Think
the
other
goal
of
this
PR
was
basically
you
know.
The
JavaScript
Sig
did
something
around
propagation.
The
javasig
did
something:
where
do
we
want
to
put
documentation
that
helps?
People
do
instrumentation
such
that
such
that
we
can,
you
know,
have
consistency
across
instrumentation.
Where
do
we
want
these
guides?
Where
do
we
want
this?
C
Because,
because
I
actually
think
I
understand
what
both
Daniel
and
Anthony
are
saying
around,
if
you're
interested
in
something
you
should
have,
you
know
deep
knowledge
of
what's
going
on,
but
then
again
like
to
some
extent
some
people
are
coming
into
the
light.
The
community,
you
know
like
they're,
saying
Hey
I
want
to
do
Rust.
Oh
look,
there's
no
AWS
instrumentation!
Let
me
go
build
that.
Can
we
have
some
guidance
or
like
documentation
of
what
we
did
in
other
languages
that
folks
can
use
there?
I
think!
C
That's
a
valuable
thing
and
I'd
like
to
see
it
somewhere.
It
does
not
have
to
be
in
the
specification.
Yeah
Jack
mentions
that
we
have
supplementary
guidelines
and
metrics,
which
is
non-normative.
Does
it
make
sense
to
have
instrumentation
supplementary
guidelines
where
we
can
share
things
that
we
built
in
best
practices
for
instrumentation
within
a
hotel
like
just
so
sigs
can
work
with
each
other.
G
M
L
Oh,
what
I
wanted
to
mention
in
messaging
semantic
conventions?
We
came
to
the
problem
that
spark
language
like
it's
very
normative,
it's
very
short,
and
sometimes
we
want
to
provide
motivations,
and
we
want
to
explain,
for
example,
how
backhands
can
visualize
things
why
we
added
this
and
we
didn't
have
a
place
for
it
in
semantic
conventions,
of
course.
L
So
we
thought
that
maybe
we
can
add
a
documentation
at
open,
Telemetry
IO,
where
we
explain
reasons
and
see
how
things
should
how
instrumentation
should
do
things
and
we
don't
have
to
figure
it
out
right
away.
Maybe
we
can
start
there
and
see
how
it
goes
and
to
make
it
more
formal
later
on.
If
there
is
any.
C
I
understand
the
concerns
around
wanting
the
specification
and
wanting
some
controls
around
it,
which
is
why,
maybe
you
want
to
have
you
know
at
least
the
approver
maintainer
status
before
you.
Let
you
know
before
you're
able
to
merge
into
this
thing,
but
yeah
I
think
there's
a
lot
of
value
there
myself.
M
C
D
It
it
doesn't
see
it
personally.
It
seems
like
having
this
like
maintainers
repo
isn't
is
like
fairly
equivalent
to
just
having
non-clearly
non-normative
advisory
stuff
in
the
spec
personally,
but
I
don't
have
like
a
strong
opinion
on
it,
I'm
just
pointing
out
that
those
two
things
feel
fairly
equivalent
to
me.
D
G
So
if
we
pop
the
sack
a
bit
further
back
though,
and
go
back
to
the
discussion
of
separating
the
semantic
conventions
from
the
spec
I,
think
that's
a
very
similar
situation
right.
The
spec
is
here's.
What
the
API
is.
Here's
what
you
have
to
do
to
build
an
API
and
an
SDK,
and
this
meant
to
conventions,
are
here's
how
you
utilize
it
here's
what
you
can
do
with
it.
D
But
it's
but
the
with
the
semantic
conventions.
It's
not
we're
not
talking
about
advisory
commentary
stuff.
It's
like!
We
really
need,
like
a
separate
version
number
for
those
things
just
coming
out
of
the
semantic
conventions
working
group
it.
It
looks
like
a
separate
group
of
maintainers
and
a
separate
version
number
that
can
get
major
version
bumps
specifically
related
to
semantic
conventions.
It's
just
so
just
to
be
clear.
It's
you
know
what
whether
we
agree
to
do
that
or
not
and
I
think
we
should.
C
So,
like
that's,
the
semantic
inventions
cannot
say
you,
you
know
you
must
use
X
or
Y.
It's
like
here's,
this
value,
here's
what
it
means
is
what
it
enforces
or
what's
like
in
scope
for
it,
everything
else
is
non-normative
and
those
guidelines
are
good,
they're
useful.
They
help.
Instrumentation.
Authors
like
this
is
good
for
the
community.
What
what
Tyler's
trying
to
implement
here
I
think
is
overall
good
for
the
health
of
AWS,
instrumentation
and
otel
of
making
it
consistent,
so
I
think
like
from
that
standpoint.
How
do
we
achieve
that
benefit?
C
What's
the
right
way
to
do?
It
is
kind
of
the
open
question
and
where
to
put
it
so
anyway,
we're
we're
out
of
time
totally
out
of
time
for
the
spec
meeting,
so
I
think
we're
gonna
have
to
take
that
second
question
offline.
It
seems
like
the
hook
to
allow
instrumentation
to
be
specific.
It's
already
in
the
spec,
we're
all
good
so
we'll
take
that
area
off
the
table.