►
From YouTube: 2022-10-11 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
B
Hey:
hey
everybody.
Do
we
start?
These
are
all
right.
We
are
three
minutes
past
time.
So,
let's,
let's
rock,
thank
you
for
joining
at
your
names.
Please
do
the
gender
if
you
haven't
okay,
let's
go
to
the
first
item,
Riley
looking
for
comments
feedback
on
the
this
issue
about
unique
request,
ID
another
packet
metadata.
C
Yeah,
so
so
we
have
a
group
of
people
in
Microsoft
working
on
the
climate
background
service
and
they
like
they
are
trying
to
support
otlp
injection
now,
and
the
architect
was
talking
to
me
regarding
how
to
support
large-scale,
like
service
running
being
able
to
support
icla.
So
one
thing
he
mentioned
is
seems
to
be
a
like
a
way
to
detect
duplicated
requests.
D
Hey
Riley,
I
I
commented
on
the
issue,
so
this
this
asks
for
three
different
things,
one
of
which
was
the
the
unique
ID
per
request
which
we
did
have
a
PR
for
in
the
past.
We
discussed
it
with
with
Josh
and
bogdon
I
believe
and,
and
we
found
that
it's
not
so
easy
to
do
when
you
also
have
a
collector
or
any
other
intermediary.
D
So
there's
a
couple
of
issues
anyway
raised
there
in
the
original
PR
that
this
proposal,
the
issue
doesn't
doesn't
address
I
think
we
probably
should
discuss
if
there
is
a
way
to
solve
these
issues,
but
whatever
the
proposal
is,
it
needs
to
address
those
right,
yeah
and
the
other
two
things
anyway.
I
commented
on
those
I
think
one
of
those
is
probably
unnecessary,
the
other
so
because
the
server
can
compute
that
the
other
is
probably
also
it
just
can
become
a
metric
anyway.
I
posted
my
thoughts
there
on
the
comments.
C
The
example
I
want
to
give
is
like
opengl
or
csis
in
the
web
pages
like
certain
vendor
can
have
additional
extension
to
CIS
that
that
is
not
accepted
by
the
w3c
standard
at
that
moment
and
once
they
prove
that's
working
well,
maybe
after
two
years
it's
moved
to
the
standard
so
for
protocol
thing
it's
one
to
avoid
us
like
ending
up
with
five
years
later.
Everyone
implemented
this
type
of
thing.
Then
we
start
to
conversion,
so
so
I
I
feel
like
maybe
the
the
folks
from
the
Microsoft.
The
backend
would
have
energy
to
help.
C
D
I
think
it's
it's
a
good
idea
to
discuss
the
extensibility.
We
we
have
two
possibilities
here.
One
is
you
you
can
you
can
extend
some
capabilities
by
recording
metadata
in
the
envelope
in
the
request,
headers
right
so,
for
example,
this
this
unique
request
ID
could
be
actually
in
the
envelope
right,
but
the
other
also.
Is
it's
not
always
per
request
right?
D
Maybe
you
want
to
carry
some
data
per
data
point
per
record,
which
then
requires
the
that,
whatever
the
extension
point
is
to
be
inside
the
payload,
so
it
doesn't
work
if
you
try
to
put
it
in
the
envelope.
I
think
it's
worth
discussing
for
the
agent
management
protocol.
We
are
doing
this
discussion
right
now,
where
we
found
the
need
that
inside
the
payload
there
is
a
need
to
have
some
places
where
you
can
do
some
customization
of
the
data
that
is
being
recorded
So
anyway.
D
I
think
it's
it's
worth
discussing
generally
the
extensibility,
and
maybe
this
is
how
you
do
that
right.
So
if
we
decide
that
you're
right,
we
don't
want
this
as
a
general
purpose
capability
on
otop,
then
for
particular
vendors.
They
can
choose
to
do
it
to
implement
it,
using
that
whatever
the
the
generic
extensibility
mechanism
is.
B
Okay,
another
comments
on
that
I
guess
so
in
that
case,
let's
move
to
the
next
item.
Okay,
the
next
one,
I
put
it
there.
It
was
a
discussion
the
chicken
and
Judy
were
having
and
we
these
girls
are
in
the
TC
as
pointed
out
by
tigrender,
and
basically
the
approach
is
that
we
want
to
go
with
only
cable
case
and
the
reason
is
that
open
Telemetry
itself
is,
you
know
we
are
the
only
producer
at
this
time
and
we
want
to
simplify
the
life
of
consumers.
B
You
know
so
for
them
having
a
single
way
of
representation
is
better
and
there's
initial
approval
here,
with
the
reasons
I
think
it's
looking
good,
we
have
enough
approvals,
I,
don't
know
whether
anybody
wants
to
say
anything
else.
D
I
just
want
to
make
it
clear
that
the
pr
that
I
submitted
originally
is
not
what
it
is
right
now.
It's
the
I
guess
the
opposite
of
what
it
was
right.
I
changed
my
mind:
I
people
convinced
me
that
this
is
the
right
approach
and
and
I
dismissed
the
original
approvals.
But
if
anybody
did
take
a
look
at
the
original
PR
and
so
that
it's
good,
maybe
you
want
to
take
another
look
right
and
especially,
if
you
need
a
proof,
I
believe
enter
the
end.
B
Yeah,
that's
a
good
thing:
yeah,
that's
a
good
call!
Yeah,
yeah,
yeah,
yeah,
yeah
I.
Think
that
everybody
who
has
approved
that,
of
course,
because
you
dismissed
their
previous
approvals,
they
have
to
go
and
contribute
that
but
yeah
just
just
in
case
yeah
and
as
I
said
before,
we
have
like
enough
approvals.
So
let's
wait
probably
four
days
just
in
case
I,
don't
know
whether
anybody
has
any
comment
at
all
here.
B
B
A
E
Yeah,
sorry,
so
right
now
we're
still
fighting
over
a
few
design
docs
in
the
TC.
Before
we
kick
that
off,
I
was
trying
to
have
a
design
dock
out
before
we
start,
but
I
think
we're
actually
going
to
start
with
something
different.
So
I'm
going
to
schedule
that
now
today
and
we'll
have
the
first
one
next
week
and
our
first
topic
is
going
to
be
on
what
constitutes
a
breaking
attribute
change
for
metrics.
E
Because
I
think
it's
different
than
traces
and
we're
going
to
talk
about
what
that
means
and
what
that
is
so
yeah
I'll
schedule
that
for
next
week,
that'll
be
our
first
topic,
which
I
think
is
somewhat
unrelated
to
a
bunch
of
the
discussions
we're
having
in
the
TC
right
now,
but
effectively
we're
still
a
little
bit
at
an
impasse
of
how
to
proceed
on
some
other
issues.
That
I
think
are
higher
priority,
but
harder
to
deal
with.
F
B
A
B
F
Yeah,
so
basically,
as
I
brought
there,
my
main
motivation
is
future
parity
between
all
the
exporters,
and
we
already
have
compression
settings
for
otlp
and
in
the
Java
SDK.
The
jigan
Zipkin
exporters
also
have
the
capability
Zipkin
even
defaults,
to
to
reduce
the
compression
by
default.
This
is
just
how
it
is
at
the
moment
and
in
our
use
case,
so
I'm
working
with
you
we're
doing.
F
Mqtt
network
is
sometimes
the
more
important
resource
of
a
CPU
and
because
you
have
millions
of
clients,
so
networkers
can
be
quickly
saturated
and
for
us
it
would
be
just
a
nice
thing
to
to
have.
B
Yeah
I
mean
my
take
on
yeah
is
that
it
makes
sense
to
have
such
environment
variables,
but
we
need
experts
from
both
City
and
jaguar
too
bad
whatever
we
do.
You
know
so
Yuri
skudo,
who
is
he
was
he's
been
cc'd
here.
I
hope
we
can
poke
him.
He
may
know
better
and
give
his
opinion
for
sip
yeah,
okay,.
C
C
So
if
you
have
a
compelling
reason
why
you
want
that
option,
it
might
help
us
number.
Two
is
there's
some
ongoing
discussion
about.
Should
we
even
departize
or
deprecate
the
year
during
starter,
because
Jager
officially
start
to
recommend
otlps
as
the
investment.
So
do
we
want
to
add
additional
thing
on
top
of
Jaeger
or
we
should
actually
plan
for
a
duplication
path
and
and
avoid
any
further
work.
C
F
Okay,
I
think
that
there
already
have
been
I
mean
there
was
like
at
least
on
the
Java
SDK,
multiple
PRS,
already
to
switch
the
defaults
and
I
think
there
were
a
lot
of
benchmarks
already
provided
for
for
that.
For
me,
it
is
just
the
the
the
the
possibility
to
configure
it
right.
F
I
mean
with
with
with
Jack
I'm
working
on
just
the
the
programmatic
way
in
the
Java
SDK.
That's
I'm,
sorry
for
all
the
other
languages.
That's
that's
the
only
one
we're
using
so,
and
it
was
just
the
last
step
to
add
it
to
the
auto
configuration
as
well,
and
just
Jack
just
made
me
aware
that
this
touches
the
environment
variable.
So
it
needs
to
go
into
the
specification
right
so
so
yeah.
F
D
F
We
are
working
on
this
to
make
it
to
get
the
feature
parity
in
Java,
so
the
underlying
exporters
have
the
the
possibility-
and
we
we
are
just
adding
this
to
the
to
the
builders.
Basically
in
the
in
the
SDK
right
now
and
yeah,
the
the
configuration
the
environment
variables
would
just
be
the
the
cherry
on
top
for
the
auto
configuration
basically
to
expose
this
I'm.
G
So
in
Java
we
have
you,
can
programmatically
configure
any
of
your
exporters
and
there's
a
separate
artifact,
a
separate
module
that
will
interpret
your
environment
variables
and
program
and
and
build
the
equivalent
exporter
from
those
environment
variables.
So
that's
what
Auto
configure
references?
Okay,.
F
Yeah,
so
we
are
completely
vendor
neutral
to
everything
like
no
APM
vendor
right,
so
we
are
just
using
open
Telemetry
for
everything
and
we
exposed
Zipkin
and
Jaeger
as
exporters
in
our
configuration
as
well,
and
we
are
just
using
the
programmatic
way.
So
we
are
not
using
the
the
agent.
That's
our
very
specific
use
case.
So
basically,
we
as
hyphenq
really
want
to
have
feature
parity
for
all
the
exporters
because
we
use-
or
we
offer
all
these
exporters
to
our
customers.
F
So
I
personally,
would
be
fine
with
the
programmatic
changes
in
the
Java
SDK.
It
was
just
for
you,
okay,
we
have
so
far
now
it's
just
this
little
thing
with
with
the
auto
configuration
with
the
environment
variables
to
just
expose
this
for
the
for
the
Java
agent,
for
example,
as
well.
B
C
I
got
some
implementations
already
support
compression
and
the
question
is:
do
they
want
to
support
the
option
to
enable
and
disable
that
maybe
some
some
sex
don't
even
see
the
need?
They
always
want
you
to
use
compression
and
if
there's
a
strong
reason
why
people
don't
want
that
default
like
we
can't
always
add
some
option
to
enable
all
kinds
of
combinations?
F
I
mean
the
other
thing
is
just
while
working
on
this
I
discovered,
basically
that
the
defaults
are
already
different
right
for
otlp
and
Diego
I'm,
not
wrong.
Compression
is
disabled
by
default
in
Java
and
for
for
Zipkin.
It
is
enabled
by
by
default.
So
there's
already
like,
like
yeah
a
difference
so.
A
D
That's
that's
not
any
kind
of
a
random
choice.
We
we
decided
that
the
important
use
cases
when
you
have
a
collector
running
locally
and
the
defaults
of
the
SDK
is
to
send
to
a
local
host
where
you
don't
want
the
compression,
because
it's
pointless
on
a
local
host,
whereas
with
Jager
and
zipping
I'm,
not
sure
the
same
logic
applies
right,
you're,
most
likely
sending
to
non-locker
posts
if
you're
using
liquor
and
Zipkin
exporters.
So
there
it
seems
that
a
default
of
using
the
compression
is
more
more
more
sensible.
F
The
consistency,
the
consistency
from
for
me,
is
more
that
we
can
configure
it
on
all
exporters,
not
what
the
default
value
actually
is
right.
I
just
want
to
document
it.
Basically,
if
there
is
a
common
sense
like
for
Zipkin
and
Jaeger,
it
should
be
enabled
it
should
just
be
in
the
documentation,
because
at
the
moment,
I'm
not
sure
exactly
how
it
is
implemented
in
the
other
languages.
F
That's
one
thing
and
what
is
the
intent
actually
at
the
moment
at
the
moment
it
it
just
looks
like
okay,
enabled
here
this
disabled
here,
so
you
even
don't
know
it
and,
as
I
said,
you
have
no
way
at
the
moment
to
configure
it
in
the
same
way
for
all
exporters.
D
So
our
reluctance
with
this
is
that
we
don't
like
in
I
guess
the
proliferation
of
the
environment
variables
right,
there's
just
so
many
of
variables
already-
and
we
add
more
and
more
and
we're
concerned
about
that.
But
I
think
it's
I
find
myself
quite
hard
to
say
no
to
this
when
we
have
that
for
the
otopx
portal
right,
so
I
don't
know
where
we
go
from
this.
D
B
I
wanted
to
say
that
from
a
practical
perspective,
it
would
probably
start
with
Zipkin
Jagger,
probably
you
know
we
will
decide
later
whether
we
want
to
deprecated
or
not,
and
that
this
may
affect
the
environment
itself
for
Jaguars
and
about
arguments
about
whether
offering
this
or
not.
If,
let's
say
I,
mean
I
I'm,
not
a
significant
expert,
but
if
silky
recommends
like
Recreation.
B
What
was
that
I
think
that
was
probably
some
unexpected
noise,
but
if
sipkin
says
99,
we
recommend
that
compression
is
on
then
probably
there's
no
reason
to
disable
that,
but
otherwise
we
can
probably
support
that.
G
So
the
Java
sipkin
client,
which
we
delegate
to
defaults
to
have
compression
enabled
so
the
only
thing
that
would
we
would
be
exposing
to
users.
That's
what
we
do
today.
So
we
default
to
compression
enabled
because
the
the
client
that
we
delegate
to
defaults
to
that,
but
so
I
think
it
would
probably
make
sense
to
keep
zip
can
default
into
gzip
compression.
But
we
could
give
users
the
option
to
turn
it
off.
I,
suppose
that's
what
an
environment
variable
would
do.
B
F
I
mean
my
proposal
is
just
basically
two
or
three
parts
right:
first,
half
the
option
with
the
environment
variable
and
then
clarify:
basically
what
the
defaults
are
or
which
options
are
are
there
also
for
for
otlp
I
I'm,
not
sure?
Actually,
what
if
we
really
say
that
non
and
gzip
are,
are
the
both
valid
values
and
that
none
is
the
default
I'm
I
think
that
is
missing
in
the
current
specification
for
otlp
as
well.
F
B
Okay,
clarification
in
blocks;
okay,
it
makes
sense.
I
will
follow
up
with
that.
One
just
to
Triple
verify
that
yeah.
If
not
I
will
create
an
issue
and
for
Jagger
I,
don't
know
I
suggest
we
wait
to
decide
yeah,
but
another
thing.
A
C
C
You
can
see
in
the
beginning
of
the
documentation.
There
are
multiple
ways,
and,
and
this
pack
never
mentioned
you
must
use
something
like
a
thrift
over
UDP
or
hdmp,
and
so
I
wonder
like
if
consistency
is
even
a
priority
here.
I
mean
it's
always
good
to
have
consistency
somewhere,
but
there
are
places
where
consistency
is
critical.
It's
like
API,
there
are
also
places,
maybe
implementation
detail
where
writing
consistencies.
It's
a
tedious
job
and
without
good
enough
with
her.
So
I'm,
not
sure.
C
But
you
can
imagine
for
for
a
particular
programming
language
if
that
language
is
hyper,
focusing
on
high
performance
scenario
for
service,
maybe
those
those
things
compressions
would
always
be
on
by
default
and
there's
no
point
to
make
his
configurable.
But
if
it's
something
like
a
client
where
CPU
is
super
critical,
they
don't
want
to
consume
battery.
Maybe
they'll
just
send
the
data
without
compression.
G
We
do
say
the
default,
it
just
says
it
in
a
different
spot.
The
default
is
listed
as
no
value
instead
of
none,
and
so
you
know
there's
kind
of
a
discrepancy
there.
We
should
probably
update
it
to
say
that
the
default
value
is
none,
but
we,
you
know
the
implication
is
clear.
B
Oh
okay,
that
makes
sense
so
yeah
I,
guess
that
I
can
think
of
that.
I
would
create
a
PR
through
of
data
to
be
super
clear.
A
There
have
been
a
couple
of
issues
surrounding
otlp
and
having
alternate
ways
to
communicate.
Otlp
data
in
particular,
there's
a
request
for
mobile
to
have
a
new
endpoint.
That
is
all
signals,
and
that
would
require
some
sort
of
content.
Negotiation,
there's
also
one
working
on
column,
data
for
otlp,
Arrow,
I'm,
calling
it
which
would
require
some
sort
of
negotiation
to
know
if
a
receiver
speaks
the
same
language
as
the
as
the
sender
and
and
graceful
fallback,
it's
being
demanded,
I
think
for
these
for
otlp.
A
B
Yeah
they
could
be
an
interesting
follow-up.
B
We
do
yeah
for
thinking
to
me,
as
I
said
before
either,
if
the
client
that
you
delegate
to
in
Java,
at
least
for
example,
if
it
defaults
to
compression
I
I,
don't
think
there's
much
value.
If
you
ask
me
that
to
disable
that,
but
if
there's
a
real
need
like
a
real
need,
then
we
can
add
it,
but
only
till
then
that
could
be
my
suggestion
for
Jagger
I
suggest
we
wait.
B
We
try
to
solve
fast,
whether
we
we
can
deprecate
Jagger
exporters
or
not,
and
depending
on
that,
we
can
consider
what
to
do
here.
Whether
add
it
here
or
not.
Also,
we
need
some
feedback
from
Yuri.
What
that's
prompt
anyway.
G
Yeah
David,
it
sounds
like
based
on
your
specific
use
case
that
you
want
to
enable
compression,
not
disable
compression,
and
so
you
know,
you're
using
open
source
tooling,
like
Jager
or
Zipkin
and
so
Zipkin,
if
you're
using
Zipkin
the
default
already,
you
know,
uses
compression
so
no
problem
there.
If
you
happen
to
be
using
Jaeger
well,
you
can
switch
to
use
the
otlp
exporter
and
enable
compression
via
environment
variables,
so
no
problem.
There.
F
A
F
Basically,
just
I
just
tried
to
follow
it
through
and
touch
the
specification
more
by
accident,
so
yeah.
G
F
B
We
will
follow
up
based
on
what
Yuri
says,
but
yeah
for
now
we
will
clarify
this
spec
on
that.
On
that
part,.
D
So
I'm
looking
at
the
spec
right
now,
it
is
a
bit
more
nuanced
than
that.
It
says
that
the
particular
languages
of
things
can
choose
the
default
for
compression
and
now
I
remember
the
reason
that
we
did.
This
is
because
we
thought
that
for
JavaScript
in
browser,
for
example,
the
default
a
different
default
makes
sense
right,
enabled
compression
is
more
sensible
there,
whereas
for
other
languages
likely
the
default
off,
he's
more
and
more
more
sensible.
D
We,
we
I,
think
we
discussed
this
at
length
in
the
past.
So
probably
this
is
what
we
want
to
keep
there.
A
Compression
in
the
browser
is
a
tricky
tricky
topic,
though,
because
while
all
browsers
generally
support
gzip
decompression
for
responses,
gzip
compression
for
request
bodies
is
not
well
supported
and
the
gzip
dependency
is
larger
than
what
a
lot
of
people
want
to
take.
So
using
it
as
a
default
in
the
browser
is
difficult,
yeah
and
then
the
CPU
to
do
that
in
JavaScript.
D
Yeah
all
I'm
saying
is
the
spec
says
it's
up
to
the
six
to
decide
what
to
do
here
right.
The
threat
doesn't,
doesn't
Define
one
single
correct
way
of
doing
this
thing
right
so,
let's
say.
B
Yeah
but
let's
say
the
JavaScript
JavaScript
would
be
fine
if
we
say
that
by
default,
there's
no
compression
I
mean
based
on
what
you
said
from
the
JavaScript
details
about
GC
compression
from
the
client
side,
no
compression
the
full
value,
it's
okay!
It's.
A
D
G
D
D
B
F
Yeah
so
then,
basically,
there
is
just
the
option
to
add
environment
variable
for
Zipkin
or
not
to
make
it
configurable.
That
would
basically
be
the
leftover
from
from
my
proposal.
Right
and
Jaeger
I
mean
it's
news
for
me
that
it's
going
to
be
replicated
or
not,
but
yeah
totally
makes
sense.
So
to
wait
for
that
decision.
B
And
but
for
you,
the
otlp
David
utilp
parties
is
like
makes
sense,
based
on
the
discussion
we
are
having
now
yeah.
F
Totally
so
yeah
I
mean
that
every
implementation
can
can
choose
the
default
value.
I
I
basically
missed.
Probably
this
the
snow
default
and
basically
the
depth
of
the
office
back
I,
said
I,
basically
tripped
into
this
by
accident
by
just
changing
the
audio
configuration
and
then
very
kindly
said.
Oh,
this
is
this
is
not
we
can't
do
it
just
in
the
Java
SDK.
This
is
touching
spec,
but
the
specifications-
oh
yeah,
foreign.
F
And,
as
I
said,
we
basically
use
the
programmatic
way,
so
as
long
as
we
can
do
that
in
the
Java
SDK.
So
this
is
not
part
of
this
stick
anymore.
Okay,
I
would
already
be
fine.
It.
B
F
F
F
B
Yeah
yeah,
Josh,
Josh,
Suarez
working
group
I
think
correct
me
Joshua
I'm
wrong,
but
you
will
also
touch
like
semantic
conventions
that
overlap
right,
that
intersect,
sorry
that
are
used
both
mobile
metrics
and
tracing
yeah.
E
There's
there's
an
intersection
by
the
way,
the
first
semantic
convention
working
group
is
scheduled
for
Monday.
So
take
a
look
at
the
open,
Telemetry
calendar,
it
I,
there's
an
agenda
there's
our
first
set
of
topics
and
all
that
is
ready,
and
it's
it's
every
two
weeks.
So,
just
just
to
clarify
we
have
a
charter,
it's
in
the
mini
notes
for
the
the
semantic
convention
meeting.
It's
also
on
the
slack
channel
for
semantic
conventions
working
group.
E
If
you
want
to
join
that
the
goal
of
the
semantic
conventions
working
group
is
to
make
sure
that
experts
in
a
particular
topic
are
the
ones
defining
the
semantic
conventions.
E
So
what
we're
going
to
be
doing
is
figuring
out
how
to
identify
those
folk
and
enable
them
to
write
the
semantic
conventions
and
what
that
process
will
look
like
to
get
it
into
the
specification
in
a
way
that
we
think
is
more
sustainable
than
what
we're
doing
now,
which
is
people
submit
PR's
they
sit
there.
They
wait
for
pretty
much
like
the
entire
TC
to
review
every
spec
approver
to
review,
and
anyone
who
says
no
rejects
the
whole
thing
we're
trying
to
make
it
a
little
bit
better
going
forward.
F
Basically,
people
from
my
company,
we
are
working
on
the
mqtt
spec
right,
so
that's
also
I,
think
I
guess
a
well-known
specification
right,
like
HTTP
or
whatever.
So
that's
very,
very
well
specified,
and
we
would
like
just
like
to
to
get
this
eventually
into
semantic
conventions,
so
that
mqtt
spans
are
basically
defined
very
well
so.
But
we
are
very
well
aware
that
this
is
not
a
thing
of
like
two
or
three
weeks.
E
Yeah
it's
on
Monday.
So
if
you
want
to
come
and
talk
through
like
what
you
think
that
process
should
look
like
and
be
we
can,
we
can
start
working
through
that
we're
also
it's
very
similar
to
we're
talking
to
elastic
common
schema
about
also
kind
of
joining
forces
together
on
logging
semantic
conventions
a
little
similar
there.
You
know
like
you're,
on
the
specification
for
one
and
the
specification
for
the
other,
very
cool.
B
Sweet
perfect,
okay,
perfect
I
think
this
is
the
agenda
going
once
going
twice.