►
From YouTube: 2023-04-04 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
B
C
C
The
main
concern
that
has
been
brought
up
is
the
number
of
people
who
will
be
impacted
by
the
breaking
changes
in
the
HTTP
semantic
conventions,
and
so
we're
thinking
through
how
to
you
know,
I,
want
to
say,
like
minimize
that
impact
or
provide
a
way
for
a
transition
period
for
folks,
instead
of
just
dropping
in
these
breaking
changes
at
whenever
time
or
yeah
so
trying
to
provide
some
structure
around
that,
and
so
this
is
important
and
I'm
sure
that
you
know
there's
a
lot
of
things
that
we
haven't
considered
yet
and
so
definitely
want
the
you
know
broader
Community
feedback
on
this
I'd
say
the
one
of
the
the
main
idea
here
is
is
including
a
flag
in
the
instrumentation
to
emit
either
the
pre-ecs
pre-stable
HTTP
semantic
conventions
or
the
new
staple
conventions,
and
the
reason
that
we're
recommending
at
this
point
to
initially
we
had
thought
we
would
try
to
use
schema
translations
and
do
this
at
the
SDK
layer
or
at
the
schema
translation
layer.
C
One
is
that
that
doesn't
help
us
with
samplers
attribute
Samplers,
which
I
know
in
the
the
Java
world
at
least
are
used
heavily
for,
like
health
check,
excluding
health
checks
from
being
sampled
from
being
collected,
and
the
other
is
concerns
around
performance.
Josh
Sarah
did
some
prototyping
here,
and
so
we
would
think
this
is
a
simpler
way
to
move
forward
with
this
particular
change.
C
It
doesn't
give
us
the
added
benefit
of
proving
out
the
semantic.
The
schema
translations,
which
was
sort
of
like
a
separate
goal,
which
I
know
we
as
a
community
still
need
to
address,
but
I
don't
want
I
feel
like
that
is
a
bigger
task
and
will
hold
up.
Potentially
it
adds
a
lot
more
risk
to
this
stabilizing
HTTP
semantic
conventions,
then
going
with
a
flag
and
so
I
know.
C
Libmilla
is
looking
at
the
python
instrumentation
I'm,
looking
at
the
Java
instrumentation
I
know
in
the
Java
instrumentation,
for
example,
we
have
some
sort
of
reusable
core
pieces
where
we
get
the
attributes
and
then
we
stamp
we
get
the
properties
and
then
we
stamp
them
on
as
attributes,
and
so
probably
we
can.
You
know
consolidate
that.
C
We
probably
don't
have
to
do
that
across
the
you
know,
30
or
40
HTTP
instrumentations
that
we
have
I
know
that
python
has
a
good
number
and
the
other
main
concern
is
probably
JavaScript.
C
I
think
probably
has
the
most
http
instrumentations
on.
E
Javascript
actually
has
surprisingly
few,
since
almost
all
of
them
use
the
the
standard,
Library
HTTP
module
and
we
instrument
that.
So
we
get
all
of
the
various
client
modules
for
free.
D
C
Okay,
cool:
we
will,
we
will
come
looking
to
the.net
Folks
at
help
us
with
this.
Also.
C
Here
awesome:
oh,
this
is
Fish
Fresh,
who
you
tagged
here.
Yeah.
D
C
C
So
the
general
kind
of
proposal
for
timeline
here
would
be
we're
working
on
proposing
a
spec
PR.
Currently
that
will
propose
all
of
these
changes
in
HTTP
and
Network
semantic
conventions.
C
At
the
same
time,
we'll
work
on
the
prototypes
and
then
once
we
prove
out
the
prototypes
and
get
approvals
on
the
spec
PR.
We'll
merge
that
and
at
that
point
is
when
we
will
Target
for
marking
the
HTTP
semcom
as
Frozen
and
then
there's
two
sort
of
independent
mixed
steps.
One
is
to
Move
It
from
stable
to
free
from
Frozen
to
stable.
C
C
And
then
the
transition
period
we
would
Define
as
some
amount
of
time
after
this
spec
version.
X
is
released
and
we
would
say
that
any
instrumentation
package
that
we
publish
that
emits
HTTP
semantic
conventions
for
that
new
version
would
also
need
to
have
a
flag
that
can
be
enabled
to
emit
the
previous
version
so
that
users
and
vendors
have
time
to
adopt
the
new
changes.
C
Matesh
had
a
good
question
already
about,
should
we,
you
know
instead
of
emitting
one
or
the
other,
should
we
have
an
option
to
emit
both
to
how
ease
migration
I
have
a
feeling?
Folks
will
have
a
lot
of
so
first,
just
maybe
like
time
box
to
three
minutes
here.
If
anybody
has
questions
about
this,
otherwise
I
would
love
your
comments
on
the
issue.
F
So
I
had
a
look
at
lootmir's
PR,
where
she
points
out
the
a
preliminary
list
of
Breaking
changes
when
adopting
ECS
is
the
intention
there
to
adopt
all
of
these
changes
and
and
use
ecssd
foundation
for
everything
or
as
the
intention
to
use
the
current
Auto
semantic
conventions
as
the
foundation
and
only
take
over
new
attributes
where
we
see
fit
and
make
changes
where
we
see
a
like
an
an
upside
to
it,
like
I,
think
there
is
agreement
for
opening
up
http.url
to
URL
dot
full
to
make
it
more
generally
usable,
but
for
the
for
the
other
attributes,
they're
like
think
30ish
or
20ish.
F
That
would
need
to
be
renamed
without
having
any
any
reasoning
or
any
any
benefits
to
it.
I
think
would
we
also
go
with
these,
or
would
we
try
to
reduce
the
churn
and
keep
them,
as
is
if
there
is
no
benefit.
C
So
we
discussed
the
Ellen
Miller's
draft
PR
yesterday
and
so
she's,
going
to
remove
the
exception
to
error
parts
from
that
and
focus
it
only
on
HTTP
and
net
conventions.
C
And
so
I
think
it's
if
you
kind
of
want
to
have
a
general
idea.
It
is
on
oh
yeah,
you
have
this
PR
Sue.
C
The
HTTP
changes
we
are
proposing
the
net
yeah
for
most
of
these
is
what
we
are
proposing.
C
C
But
maybe
you
could
post
specific
ones,
Armin.
C
Yeah
I
think
I
thinking
here
is
that
these
are
we've
churned
these
a
lot
lately
anyways,
and
so
we
may
as
well
align.
D
F
D
Let's
just
take
it,
so
it
has
to
be
based
on
a
good
understanding
of
the
problem
to
me
so
where-
and
this
is
exactly
what
Joshua
Russia
is
trying
to
drive
the
cosmetic
convention
group
and
have
a
separate
room-
also
I
expect
folks
to
review
existing
stuff
and
have
good
understanding
about
why
we're
making
a
change
and
if
I,
change,
reasonable
or
not
and
based
on
that
make
a
good
judgment,
and
for
since
that
open
symmetry
doesn't
have
I
I
feel
it's
also
similar
like
we
should
start
with
ecis,
because
if
ECS
already
have
something
and
oftentimes
it
doesn't
have
that
it
makes
no
sense
for
us
to
start
from
the
ground
so
start
from
ECS,
but
make
sure
we
truly
understand
what
we're
thinking
instead
of
blindly.
G
On
this
one,
because,
like
trust,
your
point
like
there's,
not
a
lot
of
churn
on
like
some
of
these
attributes
and
like
it's,
it's
I'm,
just
gonna
say
it's
like
it's
frustrating
as
somebody
who
has
to
go
through
and
figure
them
all
out
and
then
rework
a
bunch
of
libraries
and
then,
like
you,
know,
publish
it
and
and
from
Riley.
What
you're
saying
is
like.
If
we're
not
going
to
just
blindly
go
to
ECS,
then
we
don't
really
have
like
any
leading
thought
on
what
our
decision
is
here.
G
D
D
It's
not
directly
related
to
UCS
even
before
this
is
assume
with
keep
changing
things,
and
sometimes
we
change
our
mind.
We,
like
we
keep
breaking
things.
The
problem
is
we're
spreading
this
thing
and-
and
we
just
want
to
rush
and
get
something
in
the
in
the
specs
and
even
without
marking
it
as
stable
folks
will
just
go
and
Implement
that,
and
this
is
a
problem,
it's
a
problem
of
spreading
thing
and
trying
to
rush
without
making
anything
stable
and
with
ecis
I
feel
like
we
have
a
stick
in
the
ground.
D
D
So
I'll
give
you
example
the
database,
their
Hardware
like
their
folks
working
on
Hardware,
not
not
trying
to
remove
the
importance
of
this.
But
my
question
is
how
many
folks
are
reviewing
the
hardware
semantic
combination
and
do
things
whatever
put
like
put?
There
will
be
stable,
maybe,
like
later
a
lot
of
folks
start
looking
and
realize.
Oh
that
Hardware
specific
thing:
it's
actually
no
title
Hardware.
It
should
be
extracted
out
the
nurse
break
engine,
so
we'll
keep
turning
until
we.
We
really
know
how
to
focus
on
certain
things.
Instead
of
spreading
thing.
A
G
Don't
know
like
I
mean
it
kind
of
did
like,
but
the
answer
is
also
like
we'll
mark
it
stable.
But
then
does
that
mean
like
I
just
stop
implementing
this
till
it
becomes
stable
because
I
don't
know
if
that's
really
an
option
and
and
like
also
I'm
hearing
from
Riley
like
like
we
are
trying
to
Target
towards
ECS
on
the
second
one
like
either
it's
like
that
is.
D
Only
thing
so
for
for
this,
like,
like
continuous,
like
moving
targets,
as
trust,
has
called
out.
We
don't
want
all
the
maintenance
to
do
it
right.
It's
it's
experimental,
I!
Think
previously,
when
you
look
at
like
trees
in
Matrix
experimental,
we're
very
clear
with
some
antennas.
Don't
try
to
follow
this
closely.
We
only
pick
specific
language.
Maintainers,
maybe
like
three
six
first
already
identified
two
things,
and
maybe
it
will
just
add
Donuts,
then
three,
six,
and
if
you
own
something
else,
that's
not
in
the
list.
G
Well,
yeah,
but
I'm
like
talking
about,
like
you
know,
just
what
we
were
looking
at
here,
like
the
net
protocol
and
the
like
the
net
pier
and
the
net
client
stuff,
like
that,
all
changed
in
114
right,
like
that
was
a
that
was
a
really
big,
disruptive
change
and
I
know.
It
took
a
lot
of
effort
on
our
part
to
get
this.
G
You
know
to
the
new
Network
Direction
and
like
I
I
have
no
problem,
if,
like
you
say,
like
okay,
fine,
like
that
was
great,
but
like
we
made
this
one
last
issue
and
we
actually
wanted
to
call
this
server
address
or
server
report,
or
all
these
other
things
like
if
you're
saying
like
as
this
is
released,
we're
going
to
be
stabilizing
it
I'm
all
on
board
but
like
if
you're
saying
like
as
we
release.
This
is
going
to
continue
for
discussion
and
like
this,
maybe.
C
Yeah,
let
yeah
let
me
highlight
here
as
soon
as
we
merge
this
PR,
we
are
going
to
Mark
the
HTTP
semantic
Convention
as
Frozen.
C
D
Yeah
and
specifically
forego
I
wouldn't
suggest
that
you
keep
close
eyes
on
this.
You
should
just
wait
for
feature
freeze
and
then
you
should
take
take
a
look
and
see
whether
the
feature
phrase
version
would
introduce
some
some
impossible
thing
for
Gola
and
how
you
plan
to
talk
about.
Maybe
it's
a
good
feedback.
We
can
make
smaller
yeah.
G
D
G
Then
we
didn't
make
that
decision
explicitly
like
when
we
made
that
decision.
It
was
like
we're
gonna,
have
semantic
conventions
in
hotel
and
there's
some
sort
of
reasonable
guarantee
that
they're
not
going
to
have
like
dramatic
changes,
but
I
mean
like
and
I'm
talking,
like
dramatic
changes
too,
like
a
lot
of
the
client
stuff
like
it
changed
the
the
meaning
when
it
actually
gets
applied
like
not
just
the
name,
and
that
was
that's
like
really
disruptive
I.
D
See
so
so
this
sounds
like
a
a
starting
back
question.
We
should
make
it
clear
that
we
don't
want
these
language
things
to
run
into
this.
Chaotic
situation
by
assuming
the
experimental
spec
is
very
close
to
stable,
right
experimental
is
technically
far
away
from
stable.
If
it's
feature
freeze,
then
you
can
assume
folks
are
not
going
to
add
a
lot
of
things
or
make
crazy
breaking
changes
following
experimentals
back
closely
and
assuming
everything
will
be
stable.
It's
just
a
wrong
assumption.
In.
D
G
C
E
Yeah
I
raised
my
hand
a
while
ago,
when
we're
kind
of
past
what
I
raised
my
hand
about,
but
I
I
four
questions
like
this,
where,
where
it's
almost
purely
subjective,
just
Net
versus
Network,
it
was
my
understanding
during
the
Otep
process
that
I
for
these
types
of
things,
we
would
default
to
the
otel
choice,
not
the
ECS
choice,
I,
don't
for
man.
I
I
should
have
thought
of
the
words
while
I
was
trying
to
listen
for
one
thing:
historic
churn
is
not
an
argument
for
future
churn.
E
That
was,
that
was
the.
The
argument
that
you
gave
was
because
the
HTTP
has
changed
recently,
because
it's
changed
recently
does
not
mean
that
we
can
continue
to
change
it
in
the
future.
E
Also
that
I
I
understand
Riley's
argument
about
not
following
experimental
very
closely
or
whatever,
but
I
did
want
to
say
essentially
what
Trask
said.
Http
is
a
great
example
of
something
that
we
can't
just
not
Implement
it's
it's.
E
It
would
destroy
the
usefulness
of
otel
if
we
didn't
Implement
any
instrumentations
that
had
experimental
semantic
inventions
because
right
now,
that's
all
of
them,
so
we
would
have
no
instrumentation,
or
at
least
no
guarantee
of
any
stability
of
any
kind
on
any
instrumentations
within
the
project
which
would
make
it
functionally
useless.
E
So
my
my
primary
goal
here
is
to
reduce
churn
as
much
as
possible,
not
just
because
I
don't
want
to
implement
a
bunch
of
changes,
but
because
there's
a
lot
of
instrumentation
being
used
right
now,
and
it's
extremely
disruptive
for
users
to
just
change
it.
E
So
I
I,
don't
know
how
in
the
future
I
think
we
need
a
policy
about.
How
are
we
going
to
resolve
these
minor
discrepancies
between
us
and
ECS
in
the
future?
Are
we
going
to
always
take
the
ECS
option?
Are
we
going
to
always
take
the
hotel
option
because
in
cases
like
this,
there
is
no
like
definitive,
better
option,
but
switching
to
ECS
is
obviously
extremely
disruptive
for
us
and
on
the
flip
side,
switching
to
otel
would
be
disrupted
for
them.
E
C
C
Let
us
pull
those
out
of
the
the
main
PR
and
put
those
in
a
separate,
PR
or
we'll
open
an
issue
to
discuss
that,
because
I
think
you
know
I
think
it's
totally
valid
and
it
sounds
like
there's
a
a
reasonable
amount
of
concern
about
that
and
I
think
when
we
see
the
scope
of
the
that
change,
that'll
help.
C
Oh
we
can
put
down
for
and
against
I
I,
don't
particularly
mind
either
way.
I
I,
agree,
I,
don't
personally
see
any
advantage
to
network
versus
Net.
E
Okay
and
then
I
guess
I
would
also
I
know.
There's
some
TC
members
on
the
call
I
would
request
that
the
TC
address
this
in
a
TC
meeting
and
come
up
with
a
consistent
policy
that
we
can
apply
moving
forward
so
that
we
don't
have
this
question
every
single
time
we
try
to
do.
We
try
to
merge
one
of
the
semantic
conventions
from
UCS.
D
H
I
I
want
to
change
the
question
if
that's
okay,
so
right
now,
we
Define
stability
by
like
declared
stability
like
if
this
thing
says
it's
stable,
we
will
treat
it
as
stable.
H
I've
wanted
this
for
a
long
time
and
I
think
it
we're
a
little
scared
of
it,
but
I
think
stability
should
be
the
stability
requirements
for
any
piece
of
our
specification
should
be
based
on
usage
and
I.
Think
that's
actually
true
for
all
of
our
code
in
open
Telemetry.
H
So
if
there's
a
highly
used
library
right,
our
notion
of
whether
or
not
we
keep
it
stable
should
be
based
on
usage,
not
based
on
whether
we
said
it
was
stable
to
begin
with
so
I,
don't
know
how
we
make
that
happen,
but
I'd
like
to
change
what
you
just
proposed
Daniel
to
be
like.
That's
how
we
start
to
treat
stability
going
forward.
H
So,
even
if
we
said
something's,
beta
or
experimental
and
we
could
break
it,
the
amount
of
usage
will
limit
us
from
doing
any
breaking
changes
because
of
the
cost
to
our
community
right
and
I.
Think
that's
the
shift
that
we
need
to
start
making
anyway.
We'll
talk
about
it
in
the
TC,
but
I
want
to
make
sure
that
that
phrasing
is
okay.
I
D
I
have
a
question,
so
how
would
the
TC
make
a
policy
without
something
to
ask
folks?
My
gut
feeling
is:
Dodge
storage
will
start
her
with
a
selective
heal
from
ECS
and
open
clam
church
and
that
group
homemade
policy.
She
said
chronologist's
job
for
policy
on
UCS,
because
it's
just
ignoring
their
their
feeling
right.
I'm.
E
C
Cool,
let
me
defer
I,
wrap
this
up
and
give
time
back.
C
Carlos
back
to
you
and
thank
you,
everyone
and
please
comment
on
the
issue.
B
Looking
forward
to
that
thanks
so
much
for
that
it
was
a
very
interesting
discussion.
Okay,
let's
continue,
then
the
next
point
is
fun.
Context
is
remote
in
otlb
I
saw
you
were
here:
yeah
yeah,
yeah,.
J
That's
me:
Emily
hi,
I'm,
fairly
new
to
this
group,
I'm
from
elastic
and
I,
came
to
resurrect
a
discussion
that
was
started
over
a
year
ago
in
October
2021.
It
was
a
request
to
expose
span
contacts
that
is
remote
in
otlp
and
there
were
a
few
for
people
who
maybe
weren't
part
of
the
discussion
or
don't
recall
what
the
options
or
what
options
were
available.
I
think
there's
a
discussion
about
using
spankind
about
allowing
the
is
is
remote
available
from
the
span
con.
J
The
parent
span
context
and
the
last
one
was
oh
using
spend
flags
for
this
and
there
was
a
pull
request.
That
is
maybe,
if
you
go
back
to
the
agenda,
the
second
second
part
of
that
agenda
item.
J
J
If
you
go
back
to
the
the
original
issue,
they're
kind
of
buried
in
the
comments
or
I
can
even
share
my
screen
if
it's
easier,
but
this
the
original.
Yes,
this
one,
this
enhancement
proposal
right.
So
the
I
think
there
was
a
comment
about
using
spankind
that
wasn't
really
an
option
because
of.
J
If
anybody
recalls
that
spankind
wouldn't
have
been
sufficient
for
describing
the
situation
that
we
wanted
to
express
as
having
a
remote
parent,
and
then
there
was
a
and
the
other
option
for
using
span
flags
that
had
some
other
kind
of
unrelated
blockers.
That
would
have
prevented
us
from
using
the
span
Flags
to
indicate
this.
K
Right
now
adding
this
property.
If
we
put
it
as
optional
in
the
protobuf,
it's
costs
unnecessary
allocation.
We
have
two
options:
either
say
that
false
does
not
mean
false
like
if
we
are
using
a
Boolean.
We
can
say
false
does
not
mean
really.
That
is
not
remote,
but
it's
also
includes
unknown
or
otherwise.
I
would
probably
prefer
an
enum
there
with
undefined
is
remote
is
local
which
will
avoid
having
unnecessary
allocations
in
the
protocol.
That's
that's
my
preference,
but
yeah.
J
Okay,
so
that,
but
that
decision
seems
like
after
we
decide
to
yes
include,
is
remote
in
otlp
right,
so
we
could
go
forward
with
this
with
accepting
this
and
then
decide
make
that
decision
afterwards.
Right.
B
After
we
need
for
approvals
from
members
of
this
team,
like
the
green
arrows
that
you
can
see
there,
we're
not
Arrow,
but
you
know
yeah
exactly
and
yeah
and
I
think
we
can
just.
We
can't
leave
probably
the
other
side
of
something
to
decide
when
we
make
this
part
of
the
specification.
B
Okay,
so
yeah,
it
sounds
like
a
plan
yeah
anybody
who
is
a
member
of
the
actual
approval
list.
Please
do
review
this
one.
As
you
remember.
We
need
Forum
approvals
there.
So.
I
H
It
has
to
be
a
Tri-State
because
of
evolution
of
the
protocol
like
existing
existing
protocol.
Users
will
not
be
able
to
fill
this
out,
and
so
you
can't
default
to
one
value
or
the
other.
You
have
to
fill
it
out,
so
we
need
an
undefined
state
for
existing
protocol
users
and
you
have
to
treat
that
undefined
State
as
unknown
four
existing
protocol
users.
So
no,
we
cannot.
We
have
to
use
an
enum
in
a
dry
state
or
an
optional
is
one
way
to
do
it,
but
it's
the
expensive
way.
So
numes
are
better.
B
Okay,
that
there's
initial
agreement
that
we
want
to
expose
these,
and
then
we
can
just
discuss
the
details
as
we
go
as
we
move
on
yeah
thanks
so
much
for
the
feedback,
then
looking
forward
to
this-
and
let's
decide
do
you
know
proposed
by
book.
That
sounds
like
a
great
option
like
it
would
trade-off.
B
L
So
this
PR
that
I
linked
here
just
got
merged
and
I
just
wanted
to
call
attention
to
it.
Any
maintainers
that
are
on
this
call
that
telemetry.sdk
in
those
resources
those
resource
attributes,
went
from
recommended
to
required
and
I
think
that's
going
to
require
some
changes
to
some
of
the
SDK
implementations.
I,
don't
think
all
sdks
include
those
by
default
and
they
should
know
because
they're
required.
So
this
is
just
an
announcement
about
that.
I'll
make
a
similar
announcement
in
the
maintainers
meeting.
B
Okay,
thank
you
so
much
for
that.
Yeah
good
call,
okay,
moving
on
then
the
next
one.
This
is
PR.
You
may
remember.
We
have
discussed
that
like
five
or
six
times
here
we
came
to
initial
agreement
after
a
few
iterations.
B
The
latest
approach-
this
is
you
know,
approved
by
Trask
himself-
is
that
we
will
keep
it
as
recommended.
You
know
these
specific
attribute
and
we
will
say
that
it
should
be
collected
only
if
any
decisions
happening.
I
think
that's
a
great
outcome,
so
we're
good
to
go.
We
have
to
approvals,
but
people's
people.
Please
review
that
as
well.
You
know
just
to
make
sure
we
are
in
good
terms.
B
So
if
there
are
no
questions
there,
the
next
one
you
put
it
there
as
well,
it's
just
calling
for
for
more
eyes.
Basically,
it's
for
adding
kubernetes
cluster
uid
resource
attribute.
Just
for
basically,
you
know
in
defining
your
clusters.
Math
would
appear
there
and
he's
mentioning.
What's
the?
H
H
We
actually
already
have
some
resource
attributes
that
I
think
are
hard
or
impossible
for
users
to
look
up
that
require
the
otel
operator
to
do
the
right
thing,
so
I
think
we're
going
to
be
a
little
more
sensitive
to
that
going
forward
as
we
try
to
stabilize
these.
So
this
is
in
here.
H
But
what
this
doesn't
tell
me
is
how
easy
it
is
to
look
up
from
various
locations
so
like
if
I'm
hotel,
if
I'm
running
hotel
in
somewhere,
how
how
do
I
look
that
up
easily
right
and
that's-
that's
I-
didn't
have
a
chance
to
look
at
this
PR,
but
I'm
just
giving
General
feedback
overall,
because
we've
been
evaluating
the
resource,
Cent
conf
and
that's
my
general
concern
with
those
some
of
those
require
the
downward
API.
That's
really
expensive
in
Kate's
requires
user
intervention.
K
Does
it
mean
that
we
shouldn't
Define
them
if
they
are
hard
to
to
get
or
or
do
we
have
to
have
a
stage
or
an
option
to
them
to
say?
Okay,
this
is
hard
to
get
it's
an
optional,
because
it's
expensive
or
some
kind
of
of
terminology
to
say
that
okay,
this
is
expensive
so
because
of
that
we
are
making
it
optional
or
or
whatever
we
call
it.
Not,
as
so
I
don't
know,
should
we
Mark.
L
So
yeah
gotcha,
it's
not
ergonomic.
It's.
H
H
I
don't
want
to
start
accepting
resource
semantic
conventions
of
attributes
where
we
don't
know
how
hard
it
is
to
get
those
attributes
filled
out
in
our
resource
detectors,
and
that's
that's
kind
of
the
fear.
I
have
right
now,
because
all
the
ones
that
are
defined
using
the
download
API
actually
require
the
operator
to
kind
of
handhold
people
to
make
it
easy
or
require
lots
of
documentation
for
how
to
use
well
in
hotel
and
use
that
Hotel.
H
You
know
resource
attribute
environment,
flag,
which
is
very
awkward
so
right
like,
but
we
we
need
to
be
very
careful
with
these
to
make
sure
that
they
are,
you
know
implemented
if
you
will
so
I
want
to
make
sure
they're
implementable
and
when
you
see
one
of
these
come
in
and
we
don't
have
any
kind
of
example
of
someone
looking
up
that
data,
we
need
to
be
very
careful.
H
K
Of
them,
some
of
them,
we
may
even
add
the
availability
or
whatever
are
available,
because
some
of
them
may
be
available
only
in
collector,
for
example,
some
of
them
may
be
available
in
sdks,
so
maybe
a
location
or
whatever
is
called
a
terminology-
I'm
not
good
with
names,
but
but
we
may
have
to
a
way
to
say:
okay,
this
is
available
in
the
SDK.
This
is
not
available
in
the
SDK
is
only
available
in
the
collect.
K
If
you
are
using
the
collector,
for
example,
I
I
think
that
would
be
another
sell
into
this
table
or
that
I
would
add
to
to
clarify
for
the
users
where
can
I
this
set
up,
because
sometimes
it's
it's
it's
impossible
to
have
it
in
all
the
sdks.
To
be
honest,.
H
Yeah,
that's
a
that's
another
great
Point.
Some
of
these
things
can
only
be
annotated
by
a
collector
and
so
making
it
clear
what
you
expect
and
how
you
expect
it
to
be.
When
you
propose
it
would
help
us
out
a
lot
in
terms
of
understanding
the
impact
and
the
the
implications
of
these
things.
Yeah
good
call.
B
Okay,
I,
don't
know
whether
math
are
you
in
the
call?
Oh,
you
are.
Okay,
I
am
sweet,
so
hopefully
we
can
improve
that
part
thanks.
So
much.
Okay!
Moving
on
yes,
Josh,
sorry
proposal
to
move
some
come
to
separate
repository
you
want
to
share
or
you
can
share
for
you.
H
I
think
I
think
well,
so
basically,
I
want
to
talk
through
the
major
concerns.
I,
don't
know
if
we
have
to
share
the
the
the
doc,
because
it's
large
and
if
people
haven't
looked
at
it,
it's
just
gonna
overwhelm
you
on
the
screen,
but
the
three
major
concerns
I
wanted
to
talk
through
now.
If
we
have
time,
let's
time
box
to
about
five
minutes,
so
we
can
move
on
because
it
could
be.
We
just
follow
up
the
discussion
on
the
on
the
thread.
H
Specifically
major
concerns
raised
the
idea
here.
The
general
proposal
is,
we
want
to
move
semantic
conventions
into
its
own
repository
right
and
it
will
evolve
separately
from
the
spec
with
its
own
set
of
version
numbers.
H
So
the
the
the
main
three
concerns
that
we
see
from
the
outside
so
far
are.
Does
this
does
generate
a
code
break
right?
How
what
happens
to
generate
code?
Because,
right
now
we
have
all
these
build
tools
defined
against
the
specification
that
we'll
need
to
move
to
a
new
repository,
and
what
does
that
process?
Look
like
my
straw,
man
proposal
that
I
didn't
put
in
there
that
I
wanted
to
kind
of
run
through
people
here
about,
because
I
think
this
is
the
folks
who
are
most
impacted.
H
One
of
the
reasons
we're
proposing
to
move
the
schema,
URL
and
move
everything
to
like
a
new
set
of
version
numbers
and
a
new
location
is
so
that
we
can
piecemeal
move
from
our
existing
tooling.
That
uses
the
current
specification
repository
to
the
new
set
of
tooling
the
new
set
of
generation
that
will
be
in
a
new
repository
and
that
migration
can
happen
at
each
maintainer's
pace.
H
So,
if
you're,
if
you
own,
you
know,
go
if
you
own
JavaScript,
you
can
take,
you
can
take
this
work
and
move
at
the
pace
that
you're
able
to
move.
The
existing
semantic
conventions
will
remain
in
the
specification
for
a
time
and,
however
long
that
needs
to
be
to
get
people
to
move
to
the
new
repo
but
effectively
we're
not
trying
to
burden
you
with
just
yet
another.
You
know
breaking
change
where
you
have
time
to
make
that
move.
The
two
things
will
live
together
right.
So
that's!
That's!
That's!
H
To
answer
the
one
question
and
I'm
happy
to
get
more
I
put
that
in
one
of
the
comments,
but
I'm
happy
to
get
more
feedback
from
people
here
on
that.
The
second
thing
is:
should
we
use
the
same
schema
version,
the
my
answer
to
that
is
basically
about
the
generated
code
in
this
migration.
H
The
reason
we
want
the
reason
that
the
proposal
includes
breaking
schema
version
and
having
a
different
schema
URL
is
to
allow
this
piecemeal
evolution
of
our
ecosystem,
from
where
we
are
today
to
where
we
will
be
and
to
kind
of,
let
us
shake
things
up
in
the
new
repo
with
how
we
lay
it
out.
H
The
last
thing
was
we
needed
to
find
clear
ownership
between
the
spec
and
semantic
conventions,
so
this
would
be
what
pieces
of
the
current
repository
are
actually
specification
and
what
pieces
are
semantic
inventions
for
those
of
you
who
don't
know
we
have
things
like
service.name,
which
is
actually
part
of
our
specification
and
not
a
semantic
invention.
It's
literally
hard-coded
that
every
SDK
has
to
provide
it.
H
Telemetry
SDK
is
another
one
that
thing
that
just
stabilized
those
will
likely
be
part
of
the
specification
over
the
next
and
I
think
this
is
healthy
for
us
to
do,
regardless
of
whether
this
Otep
is
approved.
But
we
plan
to
make
a
few
PRS
that
will
make
the
division
between
semantic
conventions
and
specification
very
clear
and
very
explicit,
so
I
think
that's
going
to
happen
regardless
of
this
Otep,
just
as
a
general
health
of
the
spec
thing.
M
I'll
take
the
next
one
there
Carlos
could
I
share
for
a
moment,
I'll,
try
and
time
box
this
to
two
or
three
minutes.
I
think
this
conversation
can
mainly
happen
in
an
issue
thread,
so
here
we
go
I
posted
this
a
couple
of
weeks
ago
after
there
was
a
little
bit
of
internal
debate
in
one
of
the
technical
committee
meetings.
M
There's
this
is
a
really
contentious
topic.
You
know:
we've
had
the
messaging
group
asking
for
an
ad
link
for
over
a
year
we
had
it
in
an
early
Hotel
spec.
It
was
removed.
Some
justification
why
it
was
removed,
had
to
do
with
sampling
I've,
been
working
with
a
sampling
Sig
for
its
entire
lifetime,
and
we've
studied
this
problem
a
little
bit
so
I
put
my
feedback
into
this
issue.
M
My
claim
is
that
we
haven't
quite
nailed
down
what
it
means
to
be
a
link
so
that
we
can
decide
how
to
do
sampling
around
links,
and
the
central
part
of
my
claim
is
that
when
you
create
a
link
to
a
span,
the
other
span
should
receive
a
link
somehow
and
without
sampling.
When
you
have
a
hundred
percent
of
data
being
recorded
is
good
enough
to
just
record
the
other
span.
M
You
put
it
together
at
the
end,
like
you
see
the
downstream
data,
and
you
can
you
find
the
other
side
of
every
link,
but
when
we're
doing
sampling
and
there's
a
and
there's
a
spin
link
to,
but
that
span
is
not
sampled.
The
other
span
loses
information,
and
one
of
my
claims
in
the
sampling
group
is
that
is
that
we
can
solve
that
by
adding
depth
and
and
flexibility
to
our
sampler
API.
M
But
this
proposal
comes
in
talking
about
links
and
how
we
want
to
add
them.
So
the
question
might
be:
how
do
we
change
our
API
and
how
do
we
change
our
data
model
to
support
changing
the
links
of
a
span
after
it
starts?
So
to
me,
a
lot
of
this.
A
lot
of
the
confusion
surrounding
this
topic
comes
both
from
that
we
don't
have
a
data
model
for
for
links,
but
also
that
we
haven't
really
explained
what
an
event
is
and
I
think
everyone
probably
has
a
different
idea
of
what
an
event
is.
M
M
One
is
through
a
logging
API
one's
through
a
stand
span,
link
or
a
span
event,
but
when
you
have
a
link,
it's
really
an
event
in
two
places
at
once,
and
so
whether
we
need
a
new
whether
we
need
a
new
API
called
ad
link
or
whether
we
could
somehow
extend
our
add
event
API
to
decorate
it
with
a
link.
We
want
to
make
sure
that
that
the
other
side
of
the
link
can
be
recorded.
M
So
there's
been
some
interesting
discussion.
I
don't
want
to
summarize
the
whole
thing,
I've
kind
of
waited
out
brief
and
brief
brief
form
here.
Both
Jack
and
Bogan
have
given
me
insightful
feedback
in
the
last
day
or
two
and
I
wanted
to
kind
of
point
at
that
and
and
say
that
this
is
a
good
conversation.
These
are
insightful
remarks
for
the
most
part,
bowden's
correct,
there's,
not
a
clear
and
strong
correlation
between
saying
that,
adding
an
event,
adding
a
link
must
be
done
through
an
event.
M
I
was
in
part
trying
to
avoid
a
breaking
change
that
the
go
that
the
go
Community
was
worried
about,
and-
and
that
is
still
an
important
topic
to
me
to
my,
to
my
mind,
event
is
already
ambiguous
and
vague,
and
we
haven't
decided
all
the
ways
that
one
can
create
an
event.
I
would
like
to
be
able
to
log
when
two
spams
have
a
link
together
and
I.
Don't
want
to
use
either
span.
M
Api
I
think
it
should
be
possible
to
create
events
without
using
any
of
these
apis
and
to
have
them
just
appear
via
data.
So
questions
are
like
what
is
the
purpose
of
a
link
event
name.
Well,
when
I
add
a
link,
something
is
happening,
I
think
it's
where
I
think
it
deserves
a
description.
Ask
the
instant
messaging
group
if
they
have
a
description
for
every
link,
added
I
bet,
you'll
find
the
answer
is
yes
and
I
bet
you'll
find
it
it's
exactly
the
same
way.
You
would
name
an
event,
that's
my
position.
M
Do
you
enforce
backward
propagation
in
case
of
a
link
between
spans
from
different
processes?
One
Edge
may
miss
I
want
to
clarify
that.
But
this
is
a
daily
model
question.
We
can
find
a
way
to
record
a
link
when
there's
no
span
on
either
side.
We
can
say
I
didn't
sample
my
spin
but
I
linked
to
a
remote
span.
M
Finally,
the
relationship
and
names
mean
do
not
carry
queer.
Information
like
this
is
to
me.
This
is
a
question
about
metadata
about
the
link.
The
the
structure
of
a
link
in
the
structure
of
an
event
are
already
like,
basically
identical
with
the
exception
of
a
sanity
and
a
trace
ID,
so
I
was
trying
to
sort
of
you
know.
We
have
a
lot
of
ambiguity
here.
We
we
could
come
out
of
the
ambiguity
by
defining.
You
know
the
way.
M
M
The
idea
that
most
important
to
me
is
that
we
have
a
way
to
sample
when
links
are
in
use
and
we
can
solve
that
problem
whether
or
not
we
call
it
ad
link
or
not
and
and
but
I
think,
there's
a
supporting
argument
here
for
calling
it
adefense
with
a
with
a
link
option,
especially
because
it's
not
breaking
that's
the
end
of
my
my
statement.
I
think
it
would
be
useful
to
carry
this
issue
in
the
GitHub
conversation
and
that's
that's
my
my
kind
of
slice.
K
Can
can
we
say
that
in
the
specification
we
add
the
capability
to
add
the
link
after
the
the
span
creation,
because
that's
the
everyone
agreed
on
that
everyone
agrees
that
there
is
a
need
to
add
a
link
independent
of
how
you
call
the
API
the
concept
of
adding
a
link
between
two
spans
after
the
span
creation
there
is
this
need,
let's,
let's
agree
on
that.
That's
that's
the
first
part
that
we
I
I
feel
like.
There
is
consensus
on
that
and
there
is
no
disagreement
now.
The
disagreement
between
me
and
your
Josh
is
I.
M
K
Maybe
maybe
but
I
think
the.
K
K
M
K
So
so
there
is
a
small
difference
between
all
the
other
examples
in
this
one,
which
is
in
right
now,
everything
that
you
mentioned
they
are
still
represented
as
events
on
the
wire,
but
this
will
be
represented
as
a
link
on
The
Wire
and
that's
where,
where
I
I
see
a
a
difference
and
even
explaining
to
the
user
that
hey,
if
you
put
this
property
on
the
ad
event,
is
no
longer
going
to
be
an
event
on
The
Wire,
it's
going
to
be
a
link
on
The
Wire,
that's
where,
where
I
don't
know,
if
that's
the
right
thing
or
not
so
again,
I
I
think
we
are
here
debating
only
the
the
decision
of
reusing
that
API
versus
adding
a
new
API
and
not
not
the
the
the
concept
of
of
supporting
the
the
the
the
behavior
of
adding
links.
B
Yeah,
we
only
have
three
minutes:
let's
try
to
see
what
we
can
cover
Tristan,
yeah
I
think
you
have
a
PR
there.
N
Yeah,
this
is
quick,
make
note
that
I
opened
the
pr
this
morning
about
something
we've
discussed
in
here
before
this
makes
official
to
decorators
on
span
processors
being
removed,
I
wasn't
sure
about
doing
it
before,
because
technically
it's
a
backwards,
change
a
backwards,
incompatible
change,
but
it
feels
like
it
needs
to
be
done.
So
if
people
can
take
a
look
at
that.
B
Yeah
there's
a
pair
of
approvals.
There
there's
a
question
by
Anthony,
so
yeah,
it's
looking
good.
Thank
you
for
that.
Let's
continue
discussing
the
offline
as
well
Trask,
you
said
no
need
to
discuss
in
the
meeting
HTTP
7
com
stability
working
group
requesting
more
reviews
on
a
few
PRS.
Please
take
a
look.
Market
instrumentation
units
and
instrumentation
types
sections
are
stable
at
the
second
West
is
adding
recommendation
to
use
non-profix
units
for
metric
instruments
and
finally
add
warning
about
that
net
attributes
which
are
used
by
http
semicon.
B
Okay,
please
review
that
those
ones
three
of
them
more
than
enough
finally,
handling
of
YouTube
recording
of
these
meetings.
Please
indicate
your
preference
and
let
other
knows
about
this.
This
is
an
important
issue
that
we
also
discussed
yesterday
in
the
maintenance
meeting
yeah.
Please
leave
your
comment
there.
Sadly,
we
don't
have
more
time
to
discuss
that
here
we
have
one
minute
left
or
less
than
that.
Actually
thanks
so
much
for
that.
Let's
continue
discussing
also
the
is
remote
part
is
being
discussed
in
the
chat.
B
Let's
please
put
those
comments
in
the
actual
tab
and
hopefully
we
can
move
on.