►
From YouTube: 2023-03-20 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
C
C
B
We
we
started
our
2023
with
three
top
priorities
and
we
ended
with
four
top
priorities,
but
it's
kind
of
the
same
thing
as
as
what
you're
suggesting
is
like
one
of
them.
We
couldn't
devote
enough
resources
to
so
they
added
one
for
like
small
projects.
Basically.
C
A
A
A
B
Sorry,
man,
that's
that's
like
the
worst
of
all
worlds.
A
B
B
And
we
can
focus
on
happier
things
basically.
B
All
right,
it's
about
five
after
so
I-
think
we're
gonna
get
started.
I
I
have
not
I
actually
forgot
to
triage
new
and
incoming
issues
into
here.
Outside
of.
If
you
take
a
look
at
our
board,
we
take
a
look
at
blockers
for
semantic
invention,
stability
for
HTTP.
Specifically,
what
do
we
have
two
of
these,
but
there's
a
come
on
come
on
computer
make
this
make
this
wider.
B
This
is
ECS
related
things.
This
is
non-ecs
related
things,
that's
right.
So
if
we
look
at
blockers
for
HTTP
semantic
convention,
stability
same
old
same
old,
a
little
bit,
standardization
of
units
is
needed.
B
That
I
think
we're
continuing
that
discussion
in
the
spec
call,
not
here
Define
what
constants
breaking
changes
for
metrics
I,
don't
think
I,
don't
think.
Riley
you've
approved
the
document
you
reviewed
it,
but
we
that
document
needs
some
more
approvals
to
get
through
and
it
is
a
significant
change.
I'm
actually
having
trouble
on
that
one
with
getting
reviewers
you'll
see
it
in
the
agenda
as
the
the
top
thing
to
talk
about
so
we'll
get
into
that
in
a
second
Define.
What
constitutes
breaking
change
for
Trace?
B
That's
the
same
thing
as
breaking
changes
for
metrics.
That's
the
same
PR
default
to
seconds
is
similar
to
standardization
of
units
attribute
requirement.
Levels
need
to
be
marked
stable,
I
believe
Trask
has
a
PR
that
already
went
through
for
that,
or
at
least
fixed
up
some
things
and
we're
waiting
to
mark
that
stable,
so
I
think
that
one's
in
good
progress
add
schema
translation
to
remove
metric
attributes
that
are
newer
than
the
user's
pin
schema
version.
B
This
is
a
new
one
that
I
think
is
worth
calling
out
and
finding
out
if
somebody
wants
to
look
at.
So
let
me
pull
this
into
the
document.
B
If
anyone
has
time
to
look
at
3288,
the
tldr
is,
when
you
add
a
new
attribute
to
metrics
right,
it
can
change
the
the
time
series
and
all
that
kind
of
thing,
so
we're
actually
looking
at
having
a
thing
where,
whenever
an
attribute
is
added,
we
denote
it
in
the
semantic
convention
URLs
and
then
we
actually
have
a
translation
to
remove
it.
B
Okay,
anyway,
I
don't
think
we
actually
need
that
for
stability.
We
just
prevent
that
change
from
happening
and
we're
good,
okay
and
then
yeah
I
might
move
that
over
Mark
General
metric
semantic
events
is
a
stable.
That
would
be
the
we
have
a
few
general
purpose
ones
that
we
want
to
Mark
a
stable
I.
Think
if
we
click
in
here
we'll
see
some
specific
ones
like
the
instrumentation
units,
which
are
not
that's
caught
up
in
the
standardization
of
units
here.
B
So
that's
all
part
of
that
same
bundle
and
should
Telemetry
stability
rely
on
schema
transformation.
This
is
another
big
one
that
I
have
a
agenda
topic
already
right
here
with
issue
with
schemos,
so
let
me
put
the
overall
ticket
number
there.
B
Okay,
all
right
so
I
think
there's
no
there's
no
new
blockers
in
the
in
the
set
of
things
that
we
have
under
status
for
getting
HTTP
semantic
convention
stable.
But
there's
two
big
things
to
talk
about
was:
is
there
any
issues
people
wanted
to
raise
that
aren't
considered
blockers
that
they
think
should
be
blockers
before
we
move
on
from
the
triage
section.
D
I
have
a
brief
question
on
the
in
the
block
of
HTTP
one,
the
last
but
one
raw,
the.
D
B
B
B
D
B
Yeah
cool,
in
fact,
let
me
come
back
here,
I
think,
given
we
are
kind
of
looking
at.
Where
was
this
where's,
the
second
one
that
one
is
in
progress?
B
This
is
in
progress
because
there's
a
PR
and
that's
in
progress
because
there's
a
PR
okay
at
schema,
this
one's
not
in
progress,
require
I
believe
this
is
in
progressed.
Anyone
should
be
a
link
to
it.
I'm
Gonna,
Leave
it
where
it
is
because
I
think
what
was
in
progress
was
there
was
a
there,
was
a
PR
to
make
some
naming
fixes
and
we're
waiting
to
Market
stable
okay.
So
let
me
leave
that
one
where
it
is:
okay,
any
any
triage
status
things
anyone
wants
to
call
out
before
we
move
on.
E
B
Cool
so
we're
starting
the
20
minute
time
box
for
Telemetry
definition.
We
want
to
provide
clear
guidance
for
what
some
conv
enforces.
This
is
a
PR
there's
a
lot
of
discussion
on
it.
If
you
haven't
reviewed
it
and-
or
you
know,
put
your
comments
on
it,
please
do
I
think
from
a
spec,
approver
standpoint,
Riley
I
think
it's
still
missing
your
approval.
B
If
you
have
a
chance
to
re-review
it,
this
is
basically
us
trying
to
Define
what
semantic
conventions
will
actually
enforce
as
a
stability
Mark
going
forward
for
metrics
traces
and
logs,
basically
what
we
can
enforce,
what
we
don't
enforce.
B
So
when
you
look
at
schema,
URL,
saying
hey,
this
will
keep
things
stable.
What
is
in
scope
for
schema
URL?
What
is
out
of
scope
for
schema
URL?
What
is
in
scope
for
expectations
for
Tool
authors?
What
is
out
of
scope.
B
Yeah
there's
a
lot
of
comments
that
I
updated
the
docs
for
that
people
haven't
marked
as
resolved
and
there's
a
lot
of
open
things.
I
I
think
we
need
to
get
some
more
approvals
from
the
spec
committee,
so
I'm
going
to
raise
it
there,
but
I
just
wanted
to
find
out
in
here.
Was
there
anything
you
wanted
to
talk
about
specifically.
A
No
there's
only
one
thing
which
we
can
handle
later:
the
the
event
API.
We
like
we,
we
link
to
some
event
like
event,
API
event
model,
but
those
parts
are
not
stable.
Yet.
B
I
see
so
we
might
have
to
fragment
that
off
into
another
part.
That
is
also
experimental
with
the
event
API.
C
B
That
sounds
perfect
all
right,
next
up
issues
with
scheming,
URL
and
collector
processors,
so
I
opened
an
issue
Against
The
Collector.
We
have
this
this
over.
So
first
of
all,
I
want
to
call
out
three
two,
nine
six.
If
you
have
a
chance
to
look
at
this,
this
is
basically
should
we
rely
on
schema
transformation
for
stability.
Do
we
need
to
make
sure
the
schema
transformation
works
for
reference?
Two
things
are
happening
based
on
this.
One
is
I'm
working
on
a
in
SDK
to
literature,
schema
conversion
utility.
B
It's
going
to
take
a
little
bit
of
time
because
of
like
how
you
have
to
implement
one
of
these
things.
There's
just
a
lot
of
processes
to
set
up
and
I.
Think
Ludmila
I
also
signed
up
to
do
the
same
thing
for
the
collector
and
Aid
in
The,
Collector,
Telemetry,
schema
converter,
but
effectively
we
have
this
thing
called
salimisher
schema.
We
added
it
about
a
year
and
change
ago.
We
have
a
deadline
of
April
where
the
specs
starts
to
allow
Telemetry
schema
changes
based
on
schema,
URL
and
considers
them
stable.
B
What
we
are
asking
ourselves
is:
do
we
have
enough
in
place
to
allow
that
to
happen?
Is
that
is
that
actually
going
to
work
for
the
community?
You
know,
but
we
basically
have
to
ask.
B
Is
this
the
right
technical
solution
to
some
extent,
and
so
one
of
the
things
that
we
discussed
previously
is,
if
I
send
instrumentation
right,
I,
send
some
Telemetry
out
of
and
in
process
SDK
right,
so
let's
say:
I
have
HTTP
and
let's
say
it's
dot:
net
I'm,
I
instrument,
the.net,
HTTP,
client,
right
and
I
send
out
some
traces
and
it
hits
a
collector
if
that
collector
changes
the
name
of
an
attribute,
it
could
now
violate
this
the
schema
conventions
right
because
the
attribute's
gone
or
the
attributes
renamed
to
something.
B
So
what
this
bug
is
is
basically
asking
the
question
of
what
should
the
collector
do
when
someone
processes
telemetry
right,
there's,
there's
some
simple
options
of
like:
should
it
erase
schema
URLs
blanket
anytime,
you
modify
anything
just
always
release
delete
it,
because
you
can't
verify
that
you
haven't
violated
it
second
thing
is:
should
there
be
enough
in
a
schema
URL
that
the
collector
could
say
this
particular
change
doesn't
touch
any
of
the
verified
attributes
and
therefore
it's
okay,
so
I
can
leave
the
schema
URL,
as
is
because
I
haven't
violated
the
contract,
or
do
we
just
ignore
the
issue
completely
and
just
pretend
like
none
of
that
happens
and
users
always
do
the
right
thing
right,
I
think
there's
those
are
kind
of
like
the
three
options
in
a
spectrum
that
we
have
here
curious
on
people's
thoughts.
B
There's
this
overall
bug
here
about
whether
or
not
schema
URL
is
going
to
actually
solve
Telemetry
stability
problems
right
and
so
this
is,
this
is
kind
of
what
I
want
to
get
after.
This
is
like
we
I.
We
should
make
a
decision
about
what
we
do
in
The
Collector
one
of
these
four.
What
are
we
leaning
towards?
What
do
we
think
we
recommend,
as
a
Sig
or
as
a
working
group
of
like
how
we'd
like
to
start
tackling
the
problem
going
forward.
E
E
Yeah
I,
don't
know
it
seems
like,
as
time
goes
on,
we
you
know
we
seem
to
be
leaning
towards
merging
with
ECS
right,
like
that's
getting
approved,
doing
like
maybe
a
big
whatever
big
changes.
We're
gonna
do
as
part
of
our
stabilization
effort
and
then
just
calling
it
done,
and
you
just
can't
change
things.
You
can
only
add
things
going
forwards
like
like.
E
B
Yeah
yeah
I
I
am
I'm
trying
to
not
give
folks
my
opinion
here.
Wow
yeah
still
providing
like
options
but
I
I,
hear
I,
hear
what
you're
saying
and.
E
I
suggest
I
still
just
to
be
clear:
I
still
suggest
we
try
to
utilize
these
things
as
part
of
dealing
with
the
changes
where
we
would
make
as
part
of
stabilizing
things
and
adopting
ECS,
and
all
of
that,
like
so
I'm,
not
suggesting
we
don't
use
it
I
think
we
would
use
it
there,
but
that
would
be
on
the
it's
still
experimental
side
of
the
fence,
not
not
on
the
other
side
of
the
fence
and
also
just
and
then
I'll
shut
up
after
this.
E
My
one
final
thing,
just
regardless
of
what
we
pick
with
what
these
mutators
do
with
the
schema
URL,
you
always
have
to
assume
the
data
getting
typed
into.
You
is
garbage
and
it
has
a
schema
URL,
but
like
nothing
in
there
really
matches
it,
and
so
our
like
schema
translators
should
be
robust
in
the
face
of
you,
know,
garbage
being
shoved
at
them.
So
in
like
that
respect,
I,
don't
I,
don't
think
it.
It
matters
too
much
I,
I,
personally,
I
think
I
would
prefer
the
URL
being
preserved.
A
Yeah,
so
to
me,
the
schema
URL
reminded
me
of
the
axisd
file
like
20
years
ago.
This
is
some
additional
metadata.
People
can't
decide
to
use
or
not,
but
I
assume
most
people
over
time.
They
would
just
ignore
this
field
or
it'll
be
considered
as
a
security
issue.
It
shouldn't
go
and
pass
the
file.
Maybe
it's
just
a
some
like
identifier,
a
vendor
will
have
a
a
list.
B
But
I
guess
the
question
I
wanted
to
ask
you
Ted
related
to
this
is
even
so
schemer
yell
is
experimental
right.
Let's
say
we
do
that,
and
Riley
I
hear
you
about.
It's
reminds
you
of
xsd
and
people
might
start
ignoring
it
or
consider
an
external
download,
a
security
issue.
B
If
it's
experimental,
we
still
this
issue,
then
of
what
constitutes
a
breaking
change
to
semantic
conventions,
meaning
when
do
we
bump
our
major
version
numbers
when
you
know
what
does
1.0
look
like
that
sort
of
thing,
and
so
the
way
I
view
the
way
I'm
viewing
the
world
is
semantic
schema
URL
is
attempting
to
allow
us
to
make
breaking
changes
without
calling
them
breaking
changes
because
there's
a
conversion
tool
right.
B
E
That
is
what
I'm
suggesting
having
gone
round
and
round
this
I
think
we
should
just
not
pretend
when
we
break
things.
If
we
do
break
things,
it
means
we're
simply
on
the
hook
for
creating
major
versions
of
the
instrumentation.
We
support
and
maintaining
you
know
both
both
Forks
essentially.
E
And
this
tool
is
useful
for
people
dealing
with
embedded
instrumentation,
where
they
don't
necessarily
have
like
control
it
changes
out
from
under
them.
For
some
reason,
we
have
a
tool
for
you
that
can
help.
You
translate
the
data
back,
but
it's
still
a
breaking
change.
E
E
B
Yeah
I,
so
the
reality
is
today
since
the
Mexican
mentions
are
part
of
the
specification.
We
can't
make
breaking
changes
because
it
would
make
the
specification
break
right.
Yes,
so
that's
again,
that's
an
Otep,
we'll
talk
about
in
a
little
bit,
but
I
just
wanted
to
make
sure
I
clarify
that
position
that
those
two
are
tied
together:
okay,
yeah
anyone
else
have
any
thoughts
on
on
like
schema,
URLs
leveraging
schemer
yells
how
we
should
treat
them
going
forward,
whatever
Rick,
because
I.
B
What
I
want
from
this
discussion
is
to
come
into
the
specsig
with
a
proposal
around
schema,
URLs
and
kind
of
what
we
suggest
going
forward,
I'm
going
to
put
together
a
bunch
of
problems
and
maybe
an
Otep
right
that
basically
says
here's
the
state
of
schema
URLs,
here's
what
they
intend
to
do,
here's
what
is
happening
in
practice
right
and
here's.
The
recommendation
of
the
semantics
convention
working
group
so
I
want
to
put
that
together,
but
I
wanted
to
kind
of
collect
folks
opinions.
Does
it
if
folks
aren't
speaking
up?
A
D
C
D
Know
about
that,
because
with
with
X
is
D,
you
would
use
it
to
to
validate
if
the
data
is
in
the
right
format
and
you
would
have
to
download
it
from
an
arbitrary
place,
as
you
said,
could
cause
a
security
risk,
but
with
with
the
old
tail
schema
or
whatever
the
the
ultimate
name
will
be
I
mean
it's
the
the
only
way
how
you
can
interpret
the
data
that
you're
being
presented,
how
you
know
what
these
attributes
are
supposed
to
mean
and
I
think
people
will
need
to
rely
on
them
to
to
some
extent.
D
But
of
course,
whether
the
data
that
you
get
conforms
with
it
or
not,
is
something
that
the
mere
presence
of
the
URL
field
doesn't
doesn't
tell
you,
even
if
AV
so
far,
going
back
to
what
what
Josh
described
with
it
becoming
like
dirty
by
Transformations.
Even
if
the
collector
would
be
a
good
citizen
and
would
add
a
dirty
or
no
longer
compliant
flag.
Some
some
other
Telemetry
sender
might
not
do
that.
F
Yeah
and
from
like
the
the
romsic
perspective
with
events,
we're
sort
of
standing
back
a
little
bit
to
see
how
this
plays
out
but
we're
we
are
looking
to
have
some
form
of
event,
definition,
whether
that's
a
URL
or
just
something
that
says.
F
Okay,
we
have
our
defined
events,
but
then
we
we
support
some
level
of
custom
events,
so
vendors
can
Define
their
own,
so
back-end
systems
can
then
validate
that
then
drop
the
event
on
the
floor.
If
it
looks
completely
invalid,
but
we
haven't
really
defined
what
that
might
look
like
until
hotel
in
general,
supported
the
schema,
URL
or
schema
definition,
depending
on
how
you
want
to
look
at
it.
F
B
That's
a
really
good
call
out
because
I
think
the
currently
the
event
I
mean
it's
still.
It's
still
experimental,
but
I
think
it's
going
to
be
stable
soon,
right
events,
don't
they
have
a
like
domain
and
name
that
are
required
in
the
simcon
for
like
logging
events
today,.
F
E
B
Yeah
all
right,
I
think
I
think
we're
gonna
wrap
this
up
now,
where
in
terms
of
time
box
for
about
two
minutes
early
but
I'll,
try
to
collate
this
information
on
schemer,
yell
and
kind
of
our
current
thoughts
and
needs
around
it
and
see
if
we
can
put
together
a
proposal
going
forward,
I
think
for
for
now
as
a
as
a
working
group
and
as
as
we
do
code
reviews,
let's
assume
like
let's
treat
schema
URL
as
a
a
nicety,
not
a
must-have
and
we'll
we'll
I'll
talk
to
tigrin,
specifically
about
changing
the
definition
of
stability
to
not
include
semantic
conventions
or
sorry.
B
The
schema
URL
and
the
ski
Murrell
will
provide
support
for
merging
back
and
forth
between
versions.
But
we
we
will
not.
We
won't
assume
that
if
schema
URL
Transformations
exist,
something
is
stable
going
forward,
at
least
in
this
committee
right
now,
sound
good,
okay,
awesome.
So.
B
I
will
write
that
down.
Meanwhile,
next
up
is
a
proposal
to
move
semantic
inventions
into
their
own
GitHub
repository
I'll.
Give
everyone
a
chance
to
kind
of
take
a
look
at
that
and
read
it
a
little
bit
and
I'm
curious
on
thoughts
concerns
things
that
need
to
be
elevated
into
the
proposal.
It's
currently
in
draft
form.
B
We
can
talk
about
why?
How,
when
and
yeah
just
curious
what
people
think.
A
Unsupported
one
major
reason
is
I
I.
Think,
unlike
like
where
we
take
snapshots
when
we
do
release
semantics,
listen,
maybe
we'll
have
like
several
versions
running
in
parallel
and
and
also
the
release
side
to
my
one
has
to
be
able
to
fix
up
on
the
slight
releases.
Many
collision
and
another
important
thing
is
I.
I
feel
semantic
convention
shouldn't
be
controlled
by
a
single
group
of
you
know.
It
should
be
spread
among
domain
experts.
If
there's
database
experts,
they
should
be
able
to
Define
whatever
they
want.
C
B
Expert
yeah
I
I
do
hate
tlas,
but
you
know
I
use
them
all
the
time.
Okay,
yeah
I
good
good,
any
any
other
thoughts,
Riley
or
concerns
I
should
say
like
things
you're
worried
about
with
the
transition.
A
B
Yes,
eventually,
so
what
what
the
proposal
has
is?
Actually
the
existing
semicomp
would
remain
where
they
are
so
the
schemer
EOS
would
remain.
The
existing
SIM
card
documents
would
remain.
They'd
just
be
marked
deprecated,
with
a
move
in
the
current
specification,
and
that
way
like
existing
instrumentation
is
not
broken.
They
still
use
the
same,
send
conf
and,
as
the
community
starts
to
migrate
to
the
new
simcomf
great,
but
also
the
new
semconv
is
probably
going
to
be
unstable.
Initially,
as
we
churn
right,
the
existing
ones
are
unstable.
B
We
just
pretend
like
they're
not
effectively,
so
it
might
even
be
better
for
us
like
to
to
allow
people
to
kind
of
move
to
the
new
thing,
and
it
might
help
us
support
this
ECS
merger.
You
know
yeah.
A
B
B
But
I
have
a
I
have
a
section
on
that
under
details
in
the
in
the
Otep.
If
it's
not
sophisticated
enough,
we
should
add
to
it.
Anyone
else.
Thoughts
concerns.
E
So
I
second
everything
Riley,
said:
I
think
it
will
be
from
just
the
versioning
perspective,
but
also
like
a
permissions,
and
you
know,
management
like
a
maintainership
perspective,
it'll
be
way
easier
to
deal
with,
because
really
it's
a
separate
group
of
people
from
the
who
we
currently
call
the
technical
committee
who
are
really
focused
on
the
the
rest
of
the
stuff.
E
One
comment:
I
have
I
put
this
on
on
the
proposal,
but
under
this
section,
as
far
as
like
how
we're
laying
it
out
as
part
of
doing
this
shift,
I'd
suggest
we
move
away
from
our
current
layout
of
like
metrics
traces,
logs
Etc
and
move
to
a
folder
structure
where
it's
just
one
folder
per
domain
and
then
under
that
domain,
you
have
all
of
this
stuff.
B
Yeah
I,
here's
here's
my
thinking
there
I
agree
with
you.
100,
except
and
I-
can
put
this
in
there
explicitly.
I
want
to
have
a
one-to-one
map
first,
just
to
verify.
We
got
it
correctly
and
then
merge
and
then
move
it
in
place.
So,
if
you're,
okay
with
that,
we
could
have
a
one-to-one
just
like
get
it
over
right
and
then
there'll
be
a
commit
which
moves
all
the
HTTP
into
the
same
directory
so
that
at
least
I
can
follow
the
trail
through
GitHub
right,
fair.
D
E
B
I
am
I
am
happy
to
make
that
part
of
the
transition
yeah
and
pull
it
across
the
other
thing
we
can
do
and
I
I
don't
know
if
you're
familiar
with
when
Scala
moved
to
get,
but
we
can
rewrite
all
of
our
git
history,
so
we
can
actually
take
the
existing
git
history,
the
spec
repo
right
and
we
can
filter
out
all
the
commits
that
are
just
the
semantic
inventions.
B
So
we
can
actually
preserve
all
of
the
commits
all
the
history
that
led
to
the
semantic
conventions
and
Deals
on
the
spec
repo
and
keep
those
commits
it
takes
a
little
bit
of
work.
I
am
not
promising.
I
can
actually
make
it
happen,
but
that's
my
that's
going
to
be
my
intent.
Worst
case
scenario:
we
just
Fork
the
spec
repo
delete
everything
not
related
to
what
we're
doing
now
and
call
that,
like
the
poor
man's
version
of
get
bisect
and
get
rebase
or
the
reversion
history
fund.
B
G
So
one
question:
I
have
and
I
don't
have
a
lot
of
weight
here,
just
because
I
I
don't
do
a
whole
lot
of
work
in
this
area.
But
is
there
a
much
interaction,
When
developing
either
a
semantic
convention
or
a
a
specification
in
working
between
the
two
like?
Will
this
effectively
create
when
trying
to
do
both
areas,
creating
two
different
places
to
need
to
do
a
review.
B
This
is
a
great
question
and
I
think
you,
you
might
know
my
answer
from
I
think
where
this
is
coming
from
I
believe
we
put
too
much
dependency
between
the
spec
and
the
semantic
convention
today.
B
If
you
look
in
almost
all
places
where
they,
where
they
converge,
where
we've
diverged
it's
places
where
I
don't
think
it
should
have
been
a
semantic
convention
to
begin
with
so
exceptions
are
one
service.name
is
another
the
the
proposal.
The
way
it
calls
it
out
is
effectively.
The
specification
is
allowed
to
Define
particular
semantic
convention,
attributes
that
are
important
to
the
spec
and
those
cannot
be
broken
then
by
the
semantic
convention
repository.
B
It's
still
allowed
to
own
that,
but
the
for
the
for
the
most
part,
almost
every
semantic
invention,
PR,
that
you
get
a
predominant
majority
of
them-
are
things
that
can
be
somewhere
external.
The
one
that
you're
about
to
raise
in
you
know
another
five
minutes.
Once
we
hit
our
time
box
is
that
one
specifically
is
interesting,
because
I
don't
think
it
should
have
been
in
semantic
conventions
which
we
talked
about
like
the
the
predominant
piece
of
it,
and
so
that's
one
where
I
I.
B
Imagine
that
that
PR
would
have
almost
entirely
been
in
the
specification
as
a
compatibility
thing
and
and
wouldn't
have
touched
them
into
conventions
in
the
new
world,
because
semantic
conventions
are
really
about.
What
are
my
attribute
names,
and
what
do
they
mean
right?
What
are
my
metric
names?
What
do
they
mean?
What
are
my
span
names?
What
are
my
event
names?
It's
not
about
like
how
to
do
things,
necessarily
it's
more
about
the
meaning
of
things
and
with
it.
B
If
we
want
to
talk
about
how
do
I
integrate
with
Lambda,
how
do
I
integrate
with
you
know,
kubernetes
I
feel
like
that
kind
of
belongs
in
in
either
some
kind
of
a
compatibility
guide
or
some
sort
of
a
reference
document
like
we
have,
for
you
know,
doing.
Protocol,
conversions
and
stuff.
G
Okay,
so
then
my
suggestion
is
I.
Support
having
this
semantic
conventions
be
like
a
separate
thing,
and
one
of
the
things
that
I
like
about
the
semantic
conventions
is
the
the
programmatic
access
of
it.
So,
like
we've
got
the
yaml
that
it's
well
structured,
so
those
places
where
you're
saying
that
the
specification
should
dictate
what
the
semantic
conventions
are.
G
Maybe
the
specification
should
have
a
similar
thing
in
that
repo,
where
just
a
few
items
that
do
need
to
be
required
by
the
specification
are
also
defined
as
a
yaml,
structured
definition.
B
C
B
B
If
you
can
comment
on
the
Otep
as
well,
that'd
be
beautiful.
Okay,
okay,
we're
almost
at
the
end
of
our
time
box
and
we
didn't
I
want
to
give
everyone
a
heads
up
that
the
ECS
merger
is
happening.
B
Riley
and
gagan
from
ECS
and
I,
probably
pronounce
your
name
wrong,
are
going
to
work
on
some
blog
posts
and
then
we're
going
to
be
doing
some
next
steps
around
ECS
I,
don't
know!
If
we're
prepared
to
talk
about
anything
specific
today,
because
we're
still
in
the
the
macro
level
like
hey,
this
is
going
to
happen.
Was
there
anything
you
wanted
to
raise
Riley
in
the
in
the
last
30
seconds
of
our
time
box,
or
we
can
add
it
to
the
bottom
of
the
agenda?
Oh.
A
It's
just
it
made
some
tiny
progress
with
with.
We
need
help
from
this
group
of
people
to
reveal
that's
all.
B
In
fact,
you
can
almost
argue
that
this
PR
to
move
some
conf
into
their
own
repo
is
basically
an
outcome
of
this,
but
anyway,
okay,
cool-
and
this
is
definitely
from
Tyler
right.
Yes,.
G
This
is
mine,
yep
go
ahead
and
kick
it
off
so
basically
and
Josh.
You've
got
full
context
here.
G
I've
been
working
with
this
PR
on
trying
to
explicitly
Define
the
requirement
that
AWS
SDK
outgoing
calls
basically
calls
using
the
AWS
SDK
should
require
and
force
the
use
of
x-ray
propagation,
specifically
because
that's
the
only
thing
that
AWS
supports,
and
so
it's
gotten
a
lot
of
reviews
but
Anthony,
while
he's
supportive
of
the
general
idea
he's
not
keen
on
the
way
that
I
have
structured,
the
the
pr
and
the
additional
information
that
I've
included,
so
he
he
thinks
that
it
constrains
aws's
future
too
much
and
a
lot
of
the
information
doesn't
belong
in
the
in
the
document.
G
I
think
that
it's
important
to
include
a
lot
of
the
the
justifications
for
doing
this,
because
it
is
relatively
unusual
and
I
think
it's
also
important
to
be
consistent
across
instrumentation,
which
is
why
I
think
it
belongs
in
a
specification.
B
So
so
one
question
one
question:
I
wanted
to
check
real,
quick,
AWS
propagation.
Is
this
something
that
interacts
poorly
with
otel's
existing
propagator
specification?
Where
you
say
like
do
this,
and
then
this
and
then
this
so.
G
Aws
is
propagation
so
like
if
we
send,
you
know,
w3c
context,
propagation,
Trace,
parent
propagation,
in
the
in
an
HTTP
request
that
gets
handled
by
a
Lambda.
That
is
fine.
G
It
does
not
work
when
you
have
something
that
gets
propagated
via
an
sqs
message
that
so
so,
let's
so,
for
example,
say
you
have
something
that
goes
via
SNS
and
then
SNS
propagates
to
sqs,
and
then
it
has
some
sort
of
like
a
fan
out.
So
this
is
a
little
bit
more
of
a
complicated
interaction
and
anytime
that
that
context
propagation
must
be
done
by
AWS.
Then.
B
When
I'm,
what
I'm
asking
is
as
an
instrumentation
author
right,
if
I'm
writing
instrumentation
for
Amazon,
if
I
do
a
generic
key
value
lookup
on
my
sqs
message
right,
the
the
key
value
injection
stuff
that
we
have
and
and
I
say,
like
you
know,
prefer
AWS
and
then
do
Trace
context.
If
AWS
doesn't
exist.
G
So
in
the
case
where
you're
looking
at
like
the
SNS,
so
so
it
should
be
SNS,
not
SMS.
B
G
It's
okay
SNS
to
sqs
that
the
message
body
will
will
transfer,
but
not
the
attributes,
I
believe.
B
I
see
so
in
that
case,
WTC
trades
context
is
completely
broken,
only
actually
works,
but
I
guess
what
I'm
asking
is
that
is
x-ray
still
a
it's
still
just
a
key
value
attribute
in
there
right.
G
Yes,
but
it
has
a
different
names,
depending
on
the
the
context
so
like,
for
example,
in
SQ
sqs
messages.
It
shows
up
with
a
different
name
than
it
does
with
like
an
acdp.
B
Okay,
so
basically,
this
is
this
is
what
I
was
getting
at
like
the
you.
The
instrumentation
has
to
be
aware
that
it's
X-ray
and
that
it's
Amazon,
you
can't
generically
just
shovel
attributes
into
some
attribute
blob.
The
way
the
open,
Telemetry
specification
works
today,
yeah
right
that
that
is
why
I
think
this
deserves
some
special
call
out,
because
effectively,
the
way
our
propagator
thing
is
defined
does
not
interact
with
us
correctly.
B
D
B
I
was
reading
those
rules,
and
so
you,
you
literally,
have
to
explicitly
hard
code
x-ray
interaction
in
some
fashion,
given
the
way
the
specification
works
today.
Yes,
is
that
correct?
Okay,
so
because
of
that,
I
am
more
than
supportive
of
having
some
sort
of
call
out
for
otel
users
to
be
like
here's,
how
this
works
in
Amazon
and
and
how
to
make
this
successful.
The
other
thing
we
could
do
is
look
at
some
specification
changes
to
support
this
scenario.
B
E
Here's
the
thing
like,
even
if
Amazon
goes
in
and
adopts
w3c,
it
still
doesn't
work
with
how
we
do
propagation,
because
how
we
do
propagation
is
we?
Don't
we
propagate
whatever
it?
Is?
You
want
the
end
user
right
like
we
specifically
wrote
the
apis
to
to
avoid
having
these
endpoints
dictate
this
stuff,
because
that's
it
creates
more
problems
than
it
solves,
but
with
the
case
of
these
specialized
systems,
it
that
still
won't
work
right
like
even
if
they
adopt
w3c
B3
headers
aren't
going
to
work.
E
You
know,
so
there
are
going
to
be
certain
places
where
the
instrumentation
has
to
just
be
kind
of
special
cased,
and
hopefully
the
situation
is
solvable,
because,
presumably
what
you're
putting
onto
this
special
case,
you
know
whatever
you're,
injecting
into
the
special
case.
You
have
equivalent
instrumentation,
that's
pulling
it
out
of
there.
E
Unlike
say
HTTP
instrumentation.
You
know
where
it's
it's
not
special
case.
Yes,
so
so
I
guess
I'm,
just
doubling
down
and
saying
I.
Don't
think
this
is
a
problem
with
how
we
wrote
the
spec.
It's
just
that
there
are
these
Edge
case
systems,
where
it's
it's,
it's
just
hard-coded
as
to
what
it
supports
and
that's
kind
of
life.
G
And
I
I
totally
expect
that
this
kind
of
thing
to
happen
in
Azure
and
in
Google
systems,
because
we
need
to
support
whatever
those
systems
internal
propagation
supports.
You
know
we
can't.
We
don't
have
control
when
it's
hap
when
that
propagation
is
happening
inside
of
a
cloud
environment
manage
services.
B
We
just
have
a
few
bugs
to
to
knock
off
before
we're
100
there,
so
it
shouldn't
be
that
complicated
for
us,
but
there
still
is
worthwhile
having
that
discussion,
because,
like
from
a
Google
standpoint,
we
actually
have
a
trust
Foundry
on
Trace
IDs
and
whether
or
not
we
can
entrust
the
randomness
in
the
trace
ID
or
we
synthesize
our
own
and
so
you'll
see
Trace,
IDs,
actually
change
with
links
and
stuff
like
that
in
our
Telemetry,
no
matter
what
going
forward
right
and
so
just
documenting
that
somewhere
in
hotels,
so
people
understand
how
this
works
I'm
happy
to
have
that,
like
as
a
gcp
thing,
so
overall
I
would
argue.
B
First
of
all,
this
is
not
a
semantic
convention.
This
is
actually
kind
of
almost
like
a
how
cloud
services
work
for
a
particular
cloud
or
like
a
compatibility,
spec
right,
but
secondarily
the
kinds
of
things
you're
you
need
to
do
for
this
type
of
instrumentation
is
outside
of
us
saying
like
here's.
This
attribute
and
its
meaning
right.
So
I
really
feel
like
this
deserves
that
compatibility
section
and
that
it
deserves
to
be
in
the
specification
and
I
think
most
of
us
here
at
supportive.
B
So
all
right,
I'm
have
I've
already
escalated
this
to
CC
to
the
TC
I.
Add
it
to
the
agenda
for
Wednesday,
we'll
try
to
talk
about
it,
then,
but
I
think
it's
also
worth
possibly
talking
tomorrow.
If
Anthony's
there
in
person,
yeah
Ted.
E
Yeah
so
I
I
agree
with
you
Josh
that
it's
it's
not
a
semantic
convention
from
the
perspective
of
I,
am
someone
consuming
data
right
and
so
I'm
looking
at
the
semantic
convention,
so
I
don't
care
about
all
this
propagation
stuff,
but
Tyler
did
do
a
thing
in
his
PR,
which
is
like
from
the
semantic
conventions.
Having
a
comment
that,
like
links
over
to
this
other
section
and
I
I,
would
like
to
stress,
I.
Think
it's
useful
to
try
to
keep
everything
in
instrumentation
author
would
need
like
present
in
ours,
semantic
convention
docs.
B
Yeah
I'm
happy
to
have
that,
but
like
what
I
don't
want,
is
that
to
be
part
of
a
document
that
has
to
be
marked,
stable,
right
or
I?
Don't
want
that
to
be
something
that
someone
who
is
looking
as
an
expectation
author
has
to
read,
or
has
to
be
part
of
like
schema
URL
or
something
like
that
right
right.
B
So
that's
why
I
think
what
the
compatibility
section
I
felt
was
the
right
place
to
put
it,
but
I'm
also
happy
with,
like
a
supplementary
guideline
of
like
here's,
how
you
write
instrumentation
for
AWS
sdks,
and
we
can
have
supplementary
guidelines
for
every
cloud.
That's
fine,
too,
but
either
way
having
the
link.
There
is
totally
fine,
not
a
problem.
E
E
Adding
commentary
right
like
commentary
is,
is
you
know
a
minor
you
know
bump,
and
this
to
me
would
just
be
commentary.
We're
not
like.
It
would
just
be
a
link
over
to
this
other
thing.
If
that
link
can
set
a
date,
we
update
it.
It's
not
something
covered
by.
You
know,
schema
URL
or
anything,
but
exactly.
B
B
Okay,
thank
you,
cool
all
right,
so
yeah,
if
you,
if
you
can
bring
it
to
the
spec
committee
tomorrow,
we
might
have
a
chance
to
talk
to
Anthony
directly
there
and
resolve
questions
there.
If
not
I
have
it
on
the
I
I'm,
adding
it
to
the
TC
agenda
for
Wednesday
it's
at
the
bottom,
but
we'll
see
how
it
goes
any
other
anything
else.
Anyone
want
to
talk
about.