►
From YouTube: 2022-10-18 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
C
E
Sure
I
think
we
were,
or
at
least
I
thought
when
I
put
this
up,
that
we
were
very
close
to
having
a
1.0
I
say
there's
at
least
an
additional
issue.
That's
coming
up,
I
think
tigrin
has
added
at
least
them
regarding
span
status,
whether
we
need
to
make
a
change,
because
the
specs
says
message
and
the
Proto
says
description,
and
the
other
thing
we
need
to
do
is
we
need
to
agree
on
what
exactly
stability
means.
I
think
this
is
the
thing
we
need
to
do
sooner.
E
Rather
than
later,
we
are
reaching
a
point
where
it's
becoming
difficult
to
maintain
open
Telemetry
at
a
non
1.0.
State
people
have
expectations
of
it
and
I
think
we
as
a
community
need
to
meet
those
expectations.
So
I
would
appreciate
any
effort
anyone
can
put
towards
getting
us
over
the
Finish
Line
on
otlpv
1.0.
F
Yeah
completely
agree:
I
have
posted
a
PR
yesterday
which
tries
to
Define
what
a
stability
means.
I
think
we
should
start
working
on
that
so
that
by
the
time
we
are
done,
we
follow
the
issues
or
remaining
issues.
Whisper
is
also
already
so
we
can
go
ahead
and
declare
the
stability
it's
PR
number
432
in
the
product,
repository
I
added
it
to
the
to
the
meeting
notes.
Here
is
for
the
message
versus
the
description.
F
F
So
essentially
what
I'm
saying
is.
It
would
not
require
any
changes
in
the
Proto
right
and
we
would
not
require
any
changes
in
the
API.
It's
simply
a
clarification.
It
explains
why
there
is
a
difference
in
the
name,
but
we
accept
that
it's
different,
because
those
are
in
stable
parts
of
the
spec
and
stable
part
of
the
product.
We
we
don't
want
to
to
break
it.
F
C
F
Seems
like
no
objections,
so
what
I
can
do
is
maybe
or
someone
else,
maybe
because
I
have
15
open
PRS
already.
Maybe
you
can
create
a
PR
to
the
to
the
API
and
the
spec
Trace
Trace
API,
and
explain
that
that
difference,
and
we
should
be
good
with
that.
F
I
guess
so
we
we
should
be
good
with
with
the
Json.
If
we
do
this,
if
there
is
any
the
only
other
thing
that
may
be
preventing
us
from
going
stable
is
any
other
issues
essentially
in
the
product
repository
right.
So
we
should
go
over
remaining
open
issues
there
and
try
to
understand
if
the
resolution
of
those
issues
requires
any
changes
to
the
proton
most
likely.
F
So
if
you
have
any
any
any
Cycles,
if
anyone
is
able
to
help
with
that,
it
would
be
great
if
you
could
do
that.
C
Okay
sounds
out
right,
so
let's
continue
yeah
of
that
offline
and
please
review
The
Wanted
series
stability,
guarantees,
PR
I,
think
that's
an
important
one.
There's
some
ongoing
discussion
with
some
feedback
from
work
done
already.
So
please
review
that
one
foreign.
F
F
So
that's
that's
what
the
pr
does
I
don't
know.
If
anybody
thinks
that
this
is
wrong,
then
then
please
object
to
the
pr.
G
The
only
thing
I
want
to
raise
is
I
feel
like
we
do
need
a
hook.
For
that
other
thing,
I
would
love
that
hook
to
be
somehow
tied
to
baggage
or
some
sort
of
interaction
with
baggage
or
context
in
a
way,
but
for
all
the
people
trying
to
throw
thread
IDs
and
Trace
IDs
and
and
session
IDs
in
scope.
I
would
really
ask
for
a
proposal
there.
That's
what
I
would
say
right.
F
H
F
So
that's
that
the
next
one
is
a
draft
PR.
So
we
had
this
open
issue
for
more
than
two
years,
I.
Think
now
about
adding
about
supporting
nested
objects
and
non-homogeneous
arrays
has
attribute
values.
F
I
think
we
recently
saw
a
number
of
use
cases
which
asked
for
this,
and
we
also
saw
a
number
of
people
saying
that
they
support
it.
So
what
I
did
is
I
created
a
draft
PR,
it's
still
a
draft
which
tries
to
show
okay
well.
What
would
that
look
like
if
we
change
the
API
I?
Did
it
also
to
kind
of
properly
reactivate
this
discussion
so
that
we
can
focus
on
it
and
decide?
What
do
we
do
about
it?
Why
do
we
really
want
it?
F
C
F
It's
it's
been
open
for
I.
Think
almost
three
years
now
so,
unsurprisingly,
there's
lots
of
lots
of
comments
and
opinions
on
that.
I
Our
heterogeneous
arrays
and
Maps
should
they
be,
should
they
be,
you
know,
handled
in
a
single
in
a
single
PR
or
are
they
distinct.
F
I
I
said
I
would
have
to
go
through
all
these
issues
and
see,
if
you
know,
are
these
issues
asking
for
one
or
the
other
or
both
I
was
wondering
if
you
could
summarize.
F
That
I
think
yeah.
You
look
at
the
use
cases.
I
I
listed
the
use
cases.
If
you
go
to
the
to
the
links
there,
they
they
explicitly
say
what
they
want
like
this
structured,
State,
Trace
right.
It
asks
for
an
array
of
maps,
which
means
it's
both
heterogeneous
array
and
in
the
map
right,
so
it
needs
both.
H
F
Nothing
same
with
with
a
trace
payload
collection
or
tap.
J
But
would
it
make
sense
for
languages
that
don't
natively
support
multi-valued
arrays
to
to
not
support
that
feature.
J
Mean
some
in
some
languages
like
JavaScript
or
dynamic
type,
you
can
make
an
array
out
of
variety
of
different
things,
but
in
other
languages
where
arrays
are
typed.
K
I
It
might
be
useful
to
prototype
this
in
a
couple
of
different
languages,
a
dynamically
type
language,
something
like
go
and
then
something
like.net
or
Java.
H
F
A
Yeah
and
one
thing
I
want
to
count,
is
in
the
environment
variables.
We
allow
people
to
specify
some
attributes
and
there's
already
an
issue
created
for
people
asking
about
how
do
I
put
something
environment
variable.
It
is
a
list
of
elements
or
it
is
a
dictionary
or
something
so
so
far
we
don't
seem
to
have
a
good
answer.
This
one
is
probably
going
to
make
things
even
more
complicated
foreign.
F
E
I
click
on
on
that
front,
though,
we've
we've
all
I,
think
agreed
for
a
while
that
environment
variable
configuration
should
also
be
able
to
be
provided
through
a
file,
or
something
like
that.
Maybe
that
can
be
the
impetus
we
need
to
finally
push
that
definition
and
given
an
easier
way
to
specify
more
complex,
attribute
structures
like
this
in
configuration.
C
F
B
Yeah
I'm
here
active,
is
a
undefined
word.
I
I
am
working
on
it,
but
just
not
every
day
for
sure.
Okay.
H
I
And
I'm
in
the
same
boat,
when
I
have
spare
Cycles
I
I
work
on
some
stuff
related
to
the
file
based
config
issue,
currently
evaluating
protobarf
and
and
Json
schema
as
like
possible
options
to
to
describe
the
schema.
C
Perfect
yeah:
it's
please
review
everybody
this
one,
this
PR,
okay,
the
next
one,
is
Matthew,
where
Chris
States
for
renting
a
year
round.
L
Yeah
I'm
around.
Let
me
try
to
describe
this,
but
basically
I've
seen
the
same
author
has
opened
PR's
in
in
the
Ruby
and
the
go
repo
for
essentially
the
same
issue,
and
the
issue
is
that
as
more
people
start
using
open
Telemetry,
you
are
getting
more
transparent,
headers
being
passed
around
and
in
this
situation
the
trace
parent
is
coming
from
a
what
this
author
is
calling
a
public
endpoint.
L
Basically,
the
parent
span
does
not
exist
in
this
user's
tracing
back
end,
so
they
were
kind
of
adding,
like
a
hook
called
public
endpoint
to
figure
out.
If
you
should
trust
this
transparent
and
record
that
parent
ID
on
the
span
or
not
and
I,
think
the
intention
with
the
trace
context.
L
Spec
actually,
is
that
you
would
use
Trace
State
for
this
situation
that
you
would
put
in
a
Trace
State
entry
for
kind
of
the
last
time
you
saw
this
Trace
in
your
system
and
you
would
probably
want
to
keep
the
parent
ID
around
and
then,
when
you
are
processing
a
a
transparent,
you
can
look
for
Trace
State.
You
can
look
for
your
entry.
L
L
So
I
think
that
I
guess
that
is
my
point.
One
is
that
I
believe
this
is
a
Trace
State
issue
and
I
would
say,
that's
probably
up
to
debate
and
then
number
two
is.
L
If
this
is
kind
of
a
Tri-State
issue,
it
seems
like
we
need
to
have
a
way
for
this
to
interact
well
with
auto
instrumentation,
possibly
like
a
a
callback
of
source
that
you
can
register
in
your
HTTP
server
Frameworks
to
be
able
to
kind
of
get
a
handle
on
the
transparent
and
the
trade
State
and
kind
of
ultimately
make
that
decision
of
how
you
want
to
parent
the
span
for
that
application.
M
Matt,
under
what
entry.
H
M
L
L
Usually
that
would
have
a
key,
and
you
had
this
notion
of
like
a
multi-tenant
key,
where
you
could
have
like
an
account
within
a
vendor
and
segment
things
out
that
way,
but
as
we
have,
as
we
have
more
users
coming
through
otel
I
guess
this
would
be
a
question
for
us
and
maybe
the
distributed
tracing
working
group
through
the
w3c
to
kind
of
figure
out
how
those
keys
should
actually
work.
Should
there
be
some
sort
of
foreign.
L
Or
should
there
be,
should
people
use
a
key
based
on
the
tracing
back
end
with
a
tenant
value
to
kind
of
figure,
things
out
or
yeah?
So
I
guess
those
are
all
things
on
my
mind.
A
L
I
think
if
you
were
to
stick
something
in
the
in
Trace
State,
like
a
parent
ID
of
when
this
phrase
was
lasted
in
your
system,
you
would
be
able
to
stitch
this
thing
up,
and
that
would
be
a
thing
that
you
could
do
by
actively
knowing
something
about
trade
state
that
you
couldn't
do
in
post,
because
Trace
state
is
kind
of
meant
to
be
this
opaque
thing
where
you
are,
you
are
meant
to
be
able
to
read
your
entries,
but
not
not
other
people's.
K
Io
started
inserting
Trace
parents
and
they
were
only
sampling
at
like
zero
two
percent,
and
so
a
user
was
getting
no
sampling
out
of
their
app
because
everything
came
in
as
they
were,
they
were
using
parent-based
sampling
in
their
application,
so
everything,
basically
everything
was
sampled
out
so
I
think
there's
some
I
mean
it
would
be
good
if
vendors
weren't
just
suddenly
doing
this,
but
it
would
still
I,
don't
know,
maybe
play
into
how
we
can
distinguish
which
we,
because
they
want
their
tracing
themselves,
but
the
user
wants
to
be
outside
of
that.
H
E
I
think
that's
an
important
element
of
this
too
is,
is
that
this
is
a
structural
need,
and
you
typically
know
before
you
even
receive
a
request,
whether
you're
going
to
need
this
or
not,
because
you
know
that
your
consumers
are
outside
of
your
trust
boundary
and
you
don't
want
to
trust
that
their
sampling
decisions
are
correct
or
that
their
Trace
IDs
are
correct,
and
even
if
you
could
trust
the
the
Trace
State
data,
that's
coming
in
I
think
that,
then
you
suggested
something
like
when
this
was
last
in
your
application,
but
that
then
requires
being
able
to
fully
round
trip
through
other
people's
systems.
M
That's
a
good
point
but
I,
first
of
all,
let's
identify
which
seed
in
our
community
should
own
this
problem.
I
I
believe
it
should
be
the
instrumentation
see,
but
but
if
anyone
has
a
different
opinion,
so.
A
It
sounds
like
there.
There
are
two
issues,
one
is
related
to
something,
and
that
can
be
a
separate
thing.
I
feel
I
always
have
your
own
sampling
decision
right.
No.
M
I
think
I
think
both
will
be
solving
Us
in
the
same
way
by
by
this
by
the
one
see
because
I
believe
that
the
option
that
we
will
offer
is
something
like
trust
or
not
trust
the
incoming
Trace
Heather
do
something
with
it
and
then,
if
you
don't
trust,
you
definitely
not
gonna.
Try
the
the
stamping
decision,
correct.
A
M
Have
you
have
you
seen?
Have
you
seen
the
section
in
the
trace
context
about
this
so
like
yeah,
I've.
M
M
So
if
you
are
clown
vendor
and
you
are
malicious
and
or
whatever
somebody
from
the
cloud
vendor-
is
a
malicious
person
and
sends,
for
example,
to
I,
don't
know
lifestep.com
since
the
trace
context,
but
they
are
on
gcp
and
then
I
find
I
find
whatever
Services
they
are
using
by
by
looking
at
the
trace,
IDs
and
stuff.
So
I
think
they
should
probably
change
their
Trace
ID
when
they
receive
address
ID
from
from
an
external
user.
Only.
M
I
know
it:
if
I
manually
generate
it
and
I
know
it
and
I,
send
it
to
lifestep.com
or
to
splang.com
and
and
then
I
can
look
it
up
on
the
other
side.
So
look
look
at
all
the
examples.
We
have
lots
of
examples
there,
but
that
being
said,
I
believe
that
we
should
not
trust
anything
from
the
trace
parent.
We
should
do
something
with
it
like
recording
a
link,
I
think
that
was
also
the
recommendation.
M
I,
don't
know
if
that
was
the
recommendation
in
the
working
group
there
in
the
trace
context,
because
they
didn't
have
the
the
data
format
for
spans,
but
I
think
we
should
record
it
as
a
link
just
to
preserve
the
information
that
it
exists
there
and
then,
and
then
maybe
we
put
it
in
the
three
state.
If
we
want
I
I,
think
that's
that's
another
thing
that
we
should
separate
between
trusting
the
incoming
things
versus
preserving
the
incoming
things.
I
think
president
may
not
be
important
for
everyone.
M
E
D
If
you're
using
some
other
system,
I
assume
you're
thinking
of
X-ray,
but
it
could
be
something
else
that
doesn't
have
the
concept
of
a
Trace
State,
then
I
assume
it
would
either
be
dropped
or
you
would
have
to
find
some
other
way
to
propagate
it.
D
L
I
was
going
to
try
to
recap
where,
where
we
are
on
this
conversation
exactly
so,
it
sounds
like
the
opinions
are
that
Trace
state
does
not
solve
this
problem,
that
we
need
some
kind
of
way
in
hotel
to
kind
of
Define
the
boundaries
in
which
you
would
trust
a
transparent,
and
then
you
would
use
that
to
figure
out
if
you
would
use
a
transparent
or
whether
you
would
create
your
own
parent
and
Link
things.
L
That's
kind
of
a
proposal,
but
whatever
the
case,
this
is
something
that
probably
needs
to
be
decided
upon
by
the
instrumentation
Sig
and
would
be
kind
of
a
the
outcome.
Of
that
would
be
a
a
universally
appliable
kind
of
option
for,
for
all
the
various
language.
Sdks.
G
I
I
disagree.
This
is
instrumentation
Sig
I
think
this
is
a
tracing
thing.
So
sorry,
it's
a
fundamental
tracing
concept
of.
Do
you
trust,
transparent,
I,
I,
agree,
that's
the
thing
that
has
to
be
solved.
I
think
there
needs
to
be
a
proposal
around
that.
You
know
as
a
cloud
provider
we
care
about
this.
We
ask
this
question
a
lot.
G
We
have
a
thing
that
we
do
I
think
it's
important
that
we
have
a
standard
answer
to
this,
that
we
all
select
of
if
I,
can't
trust
that
incoming
Trace
parent,
what
do
I
do
with
the
trace?
Let's
define
what
otel
does
and
then
see.
If
other
people
follow
suit,
there
I
think
that
makes
sense,
but
I
don't
think
this
is
an
instrumentation
concern.
This
is
a
fundamental
Trace
thing.
This
is
this
is
like:
can
I
trust,
Trace,
parent,
so
I,
I
I?
M
Okay,
Josh,
then,
then,
should
we
make
it
TC
problem
and
then
discuss
it
tomorrow
when
you
have
the
meeting
and
who
is
owning
it
and
and
coming
up
with
the
proposal.
Is
that
okay?
For
me,.
G
M
Perfect,
let's
put
it
on
our
agenda
tomorrow
and
come
up
with
a
proposal.
C
Perfect
okay!
So,
let's
hear
about
that
later
on,
okay,
let's
move
in
let's
move
on,
then
we
still
have
half
an
hour,
but
just
in
case
okay,
the
next
one
non-string
resource
attributes
in
in
environment
variables
year
round
I
forgot
the
name
of
the
person
proposing
this.
N
Channel,
it's
me
Rafael,
it's
actually
not
even
a
change.
I
would
say
just
clarifying
this
pack.
It
seems
that
there
is
a
we
discussed
this
previously
in
this
meeting
about
the
when
we
were
discussing
the
support
to
maps
and
homogeneous
arrays.
So
this
is
related
so
right
now,
if
we
want
to
use
let's
say
Java
alt
instrumentation,
with
an
application,
it's
not
possible
to
set
up
attributes
that
are
known
strings
in
a
easy
fashion.
N
N
Because,
let's
say
if
you
try
right
now,
it
will,
it
seems
that's
fairly,
silently
there's
no
warning
or
anything
so.
N
D
Yeah
I
mean
I,
don't
see
any
way
to
to
distinguish
between,
like
the
string
six
and
the
number
six
to
take
the
integer
as
a
as
a
simpler
example
than
what
you
put
there
right
without
like
escaping
rules
and
all
kinds
of
complication,
I
think
much
much
easier
to
just
say
this
doesn't
work.
N
E
I
think
it's
simpler
to
say
that
it
doesn't
work.
It's
not
a
very
satisfying
answer,
though,
because
we
do
support
these
array
and
and
other
valued
attributes
in
resources.
D
Maybe
it
may
be
simpler
was
the
wrong
word
to
use
I
think
that
the
environment
variable
configuration
is
not
like
this
is
yet
another
symptom
of
the
the
configuration
can
that's
been
kicked
down
the
road
for
like
three
years
now,
I,
don't
think
the
environment
variable
is
the
right
place
for
this.
E
D
I
I
just
think
that
if
we
added
some
sort
of
parsing
requirements
to
the
environment
variables
making
sure
that
they're
consistent
across
all
of
the
languages
and
that
they
don't
have
bugs
and
that
you
can
properly
Escape,
everything
is
just
unreasonably
complex
for
the
for
the
value
that
it
brings.
E
G
A
On
Windows,
there
used
to
be
a
very
low
limit,
but
the
later
version
increase
that
limits,
but
still
I
figure
like
environment
variable,
is
just
a
just
a
the
place
that
we
want
to
keep
Simple.
If
we
try
to
make
it
like
a
fully
like
working
system
for
whatever
I
should
just.
It
would
just
be
very
hard
for
people
to
use
like
when
you
specify
something
environment
variable
you
need
a
command
line
or
shell
script.
You
have
to
escape
again,
and
it's
just
like
horrible
for
people
to
understand.
D
A
Yeah
so,
as
Delta
mentioned
their
limits
so
maybe
moving
forward,
we
should
think
about
a
way
like
like
to
push
for
the
configuration
basis
thing.
An
environment
variable
will
just
be
one
single
thing
that
points
to
a
local
path,
whether
it's
relative
or
absolute
path,
and
eventually
figure
out
a
way
to
like
remove
all
the
existing
environment
variables,
because
it's
getting
more
and
more
compacts
and
just
hard
to
manage.
G
So
real
quick
I
want
to
put
on
a
PM
hat
for
a
second
I.
Don't
think
we
have
PM,
but
do
we
have
a
list
of
all
of
the
places
where
we've
run
into
issues
like
this,
where
we
say
hey,
let's
build
a
config
thing.
G
Let's
put
this
bug
on
that
list.
I
don't
know
who
owns
that
list
or
who
wants
it
on
that
list?
Maybe
that's
another
thing
we
should
I
should
pick
up
anyway.
Let's
make
that
list.
Let's
put
this
on
that
list
and
let's
try
not
to
again
we
we
want
to
not
block
things
for
stuff,
that's
been
sitting
for
three
years
and
never
actually
made
progress
unless
we're
actually
going
to
work
on
it.
G
In
this
case,
I
think
what
I
would
say
from
the
discussion,
I'm
hearing,
we
don't
think
environment
variables
should
solve
this
problem
so
in
in
the
sense
of
this
will
not
make
progress
without
a
config
file.
I
think
we're
we're
guaranteed
on
this
issue.
So
let's
put
this
issue
on
a
list
around
the
config
file
and
I.
Think
until
we're
ready
to
actually
talk
about
designing
that
config
file,
we
can
table
the
rest
of
the
discussion.
Does
that
sound
fair.
M
Josh
it
it
is,
or
it
is
not
so
what
I
figure
out
in
the
open
source
Community
is
lots
of
that
lots
of
times.
People
will
take
the
easier
out
and
that
easy
route
is
just
add
another
environment
variable
in
this
case,
because
we
started
with
this
path
so
on
until
we
somebody
foreign
pulls
the
trigger
and
say
we
have
to
work
on
this.
Nobody
will
start
working
on
that
conflict
fact
because
they
will
add
another
environment
variable
so.
B
I'm
I'm
working
without
it
yeah,
Jack
and
I,
have
have
looked
at
this.
It's
not
sorry,
it's
not
being
as
fast
as
I.
Think
people
would
expect
it
or
want
it
to
be,
including
me
I'd
like
it
if
it
went
faster.
I
do
know
that
also
like
Josh
Earth's,
your
point
of
like
tracking
these
things
in
a
list
I've
been
trying
to
do
that.
I
can
add
this
one
to
that
list,
but
yeah
I
I.
It's
it's.
Definitely
it's
slow.
It's
not
a
top
priority.
B
I,
don't
think
for
this
work,
but
it
seems
like
it
needs
to
be
a
higher
priority.
D
I
think
it's
the
job
of
the
TC
to
decide
whether
it's
a
priority
or
not.
And
if
it
is
to
say
we
will
not
accept
new
environment
variables
unless
there's
an
extenuating
circumstance
until
the
config
is
done.
Like
that's.
D
Decision
and
yeah
that
that's
what
the
TC
is
for,
in
my
opinion,
I.
B
Agree
sure,
but
the
TC
doesn't
direct
what
you
know.
I
work
on
you.
D
Know
no,
no,
of
course
not
I
didn't
mean
your
work
specifically
needs
to
be
sped
up.
I
meant
that
the
idea
of
configuration
needs
to
be
prioritized
as
a
project,
not
necessarily
on
your
specific
list,
and
if
you
don't
have.
G
Time
just
to
call
this
out
just
to
call
this
out
for
everybody
we
have.
We
have.
We
have
so
many
things
going
on
simultaneously
right
now
that
what
we're
trying
to
do
is
not
block
PRS
that
we
can
still
make
progress
in
instrumentation
in
the
things
we're
doing
and
yes,
configuration
hurts
a
lot
and
it's
probably
the
next
top
priority,
but
it's
not
a
top
priority
that
we
had
head
count
to
deal
with.
G
The
fact
that
Tyler
and
Jack
are
looking
at
is
awesome,
because
that
does
mean
that
maybe
we
have
head
count
to
address
this
I,
just
it's
a
hard
enough
problem
that
will
require
enough
heads
that
I
think
it'll
take
a
while
to
get
there
and
we
shouldn't.
We
should
try
to
avoid
blocking
config
as
much
as
possible
until
we
have
a
solution.
G
But
in
terms
of
like
whether
or
not
you
know,
there's
head
count
to
take
it
on
right
now,
without
someone
outside
the
TC
saying,
hey
we're
going
to
look
at
this
problem
and
solve
it.
There's
not.
We
don't
have
enough
heads
effectively.
So,
that's
why
it's
it's
not
there,
but
I
just
want
to
directly
call
that
out.
I
agree
with
you,
that's
the
job
of
the
TC.
We
just
don't
have
enough
heads
to
tackle
that
problem
right
now,
ourselves.
So
again,
thank
you,
Tyler
and
jack
for
for
addressing
it.
G
I
I
think
we
should
be
careful
about
the
environment
variables
we
add,
but
I
also
don't
think
if
there's
a
really
good
use
case
for
that
environment.
Variable
I
don't
want
to
block
it
on
this
work,
because
I
expect
the
work
to
take
a
lot
of
time
going
forward.
I,
don't
know
if
all
the
TC
shares
that
opinion
with
me,
but
that
is
a
stance
we've
taken.
In
other
cases
where
we
have
a
big
long-running
task
list
of
work
and
we
have
block
PRS.
G
E
E
G
Yeah
so
we'll
we'll
discuss
We'll,
add
to
the
agenda
we'll
talk
about
a
moratorium
on
config
variables.
Again
I
gave
you
my
stance,
but
we'll
we'll
vote
on
that.
M
So
yes
Anthony,
you
can
request
a
vote
for
for
from
TC
anytime
father
needs
you
to,
and
we
can
even
document
that
vote
publicly.
If,
if
you
want
that,
that's
that's
definitely
a
thing
that
anyone
in
the
community
care
request,
especially
somebody
who
is
an
approval
or
maintainer
on
on
this
kind
of
topics.
E
Okay,
sort
of,
like
sure,
said
he
was
going
to
put
it
on
the
agenda.
Do
I
need
to
file
an
issue
or
can
just
just
put
it
on
the
agenda
and
take
care
of
it.
He.
G
Yeah
I
would
throw
it
on
the
specification
and
that
that's
that's
a
good
call.
If,
if
we
don't
track
it,
it's
hard
to
make
sure
that
we're
making
progress,
but
we
can
put
our
feedback
of
what
we've
decided
on
the
issue.
So
if
you
open
the
issue,
I'll
link
it
to
the
thing
we'll
talk
about
and
we'll
keep
everyone
up
to
date
as
fast
as
we
can.
That
way,.
C
C
If
that
makes
sense,
and
then
we
can,
as
a
follow-up,
discuss
the
configuration
file
and
moratorium
in
the
DC,
does
that
sound
good
enough.
C
Perfect,
okay,
then,
let's
continue
with
the
rest
of
the
items.
C
The
next
one
is
about
adding
distribution
or
distro
to
the
spec
yeah.
There
was
some
discussion
back
and
forth
in
the
past
and
said
you
are
around
I.
Think
you,
you
were
the
one
proposing
this
in
the
past,
like
the
concept
I,
don't
know
whether
you
or
anybody
else
has
any
feeling
about
having
this
actual
term
to
the
spec.
J
Yeah
I
mean
I
I
do
think
we
need
to
Define
it
before
we
add
it,
though
part
part
of
what
I
have
wondered
with
the
term.
Distribution
is
so
long
story
short.
J
Currently,
there's
nothing
stopping
legally
speaking,
stopping
someone
from
creating
something
and
calling
it
open.
Telemetry
it's
possible
for
us
through
the
cncf
to
create
actual
legal
trademarks.
One
of
them
could
be
open,
Telemetry
distribution,
another
one
could
be
certified
open.
Telemetry
kubernetes
does
this
with
their
their
certified
kubernetes
implementation,
so
that
you
can
say,
if
you're
going
to
use
this
particular
term
that
guarantees
certain
things
like
certain
amount
of
compatibility
with
open
Telemetry
in
certain
ways.
J
It's
it
is
a
little
it's
a
it's
a
little
tricky
when
it
comes
to
enforcing
it.
From
from
what
I
understand,
because
it's
it's,
it's
Apache
licensed
open
source.
J
If
we
want
to
have
so,
in
other
words,
I
guess
what
I'm
trying
to
say
is
there's
two
options
for
things
we
can
do
with
the
term
distribution.
We
can
just
have
like
a
basic
term
that
we
throw
out
there
and
we
don't
worry
about
this
bigger
goal
of
creating
a
conformance
program
around
like
what
a
distribution
should
or
shouldn't
have
in
it,
but
it
is
possible
through
the
cncf,
to
do
something
like
a
conformance
program.
K
Yeah
I
think
this
should
be
outside
of
that
for
now,
because
one
thing
that
brought
this
up
I
think
is
that
python
has
what
they
call
a
distribution,
the
python
Sig
and
whether
or
not
that
whether
or
not
distribution
should
have
should
mean
third-party
vendor
wrapper
or
they
can
use
it
that
way
or
should
use
it.
That
way.
O
I
I
can
also
add
something
to
that
real
quick.
That's
why
I
added
into
the
agenda
that
this
question
around?
What
is
part
of
automatic
instrumentation
is
part
of
that
by
reviewing
all
the
different
documentations
for
all
the
different
languages.
O
I
realized
that
everybody's
using
automatic
instrumentation
slightly
different
in
the
sense
of
what
is
part
of
it
right
and
what
python
is
doing
is
that
they
say
like
hey,
there's
this
distribution
and
this
distribution
does
bundle,
instrumentation,
libraries,
exporters
and
a
few
other
things,
and
that's
what
we
call
a
distribution
where
Java,
for
example,
this
is
just
a
Java
agent
or
net,
is
now
also
working
on
this
dotnet
Auto
instrumentation,
and-
and
this
is
why
I
erased
this
issue
not
to
to
to
let's
say,
make
it
much
more
complicated
than
it
is
already,
but
but
really
figuring
out
like
hey
what
what
is
part
of
Auto
instrumentation
and
then
adjacent
to
that.
O
J
Yeah,
so
if
we
want
a
basic
definition
of
this,
one
I
would
divide
it
into
two
pieces.
One
is
a
client
distribution.
The
other
is
a
collector
distribution.
A
client
distribution
is
a
a
version
of
the
SDK
plug-ins,
potentially
instrumentation
that
it's
bundled
up
with
an
installer
of
some
kind.
J
So
there's
multiple
examples
of
these
out
there,
but
it's
it's
totally
fine
for
open
Telemetry
to
issue
distributions.
It
doesn't
have
to
be
a
vendor.
You
could
argue
that,
like
what
we
give,
people
is
always
a
distribution,
and
so
you
have
the
the
standard
open.
J
Telemetry
distribution
is
the
one
that
you're
using
when
you
use
our
docs
and
you
use
the
the
basic
building
blocks
that
we
provide
light
step,
for
example,
has
like
a
very
tiny
distro
called
the
lightstep
launchers,
which
is
basically
just
a
little
wrapper
around
the
installation
of
the
SDK
to
help
make
sure
that
the
end
user
doesn't
forget
to
do
things
like
set
the
lightstep
access.
Token,
header
and
stuff
like
that.
J
So
I
would
be
fine
defining
you
know
a
client
distribution
to
something
like
that.
Collector
distribution
I
believe
we
could
Define
it
this
time.
As
simply
a
version
of
The,
Collector,
plus
collector
contrib
plugins
that
have
been
compiled
into
a
binary
and
there's
a
whole
bunch
of
those
flying
around
right
now,
so
we
we
could
I,
don't
know
if
anyone
has
like
another
idea
of
what
they
would
want
distribution
to
me.
But
that's
what
it
means
to
me.
C
I
guess
that
the
question
that
I
have
is
whether
the
term
history
is
something
we
want
to
have
in
respect.
It
was
mentioned
in
the
past
that
probably
this
was
too
much
of
a
sales
term
rather
than
a
technical
one.
C
O
Aside
for
me,
those
two
are
a
little
bit
interconnected,
because
python
is
doing
it
that
way
that
that
what
other
languages
call
Auto
instrumentation
is
their
distribution,
which
kind
of
works
I
mean,
as
you
said,
Ted,
that
that
that's
one
way
of
looking
at
it
that
like,
if
you
take
offer
instrument,
if
you
take
instrumentation
libraries,
if
you
take
exporters,
if
you
take
resource
detectors
and
what
else
is
floating
around
there
and
put
it
together,
you
could
call
this
a
client
distribution,
then,
but
but
then
my
my
big
question
is
just
like:
let's
come
up
with
some
kind
of
consistent
naming,
I
know
that
there's,
of
course,
always
will
be
some
differences
in
languages
and
Java
will
always
have
this
term
agent,
but
but
at
the
end,
right
now,
I
personally
find
it
highly
confusing
for
an
end
user
going
into
different
language,
documentations
and
and
looking
at
different
things.
O
What
what
it
means
to
to
have
things
auto-instrumented
right
so
as
I
gave
a
list
below
there
what
what
the
different
languages
are
doing
right
now,
yeah,
that's
at
least
my
interpretation.
Maybe
I
did
something
wrong,
but,
for
example,
we
have
also
node.js
and
Ruby
that
sell
like
automatic
instrumentation
is
just
using
instrumentation
libraries,
which
is
very
different
to
to
what
you
have
in
java.net.
J
So
so
here's,
let
me
here's
how
I
would
separate
Auto,
instrumentation
or
agent
from
distribution,
because
I
think
you
can
have
both
so
in
Java,
you
have
an
agent,
but
what
pile
of
instrumentation
does
that
agent
come
with
that?
It's
willing
to
install
that's
the
distribution.
J
For
example,
some
people
might
accept
a
wider
variety
of
sourcing
from
the
instrumentation.
That's
installed
by
that
agent
for
other
people.
They
may
want
a
thinner
package
of
instrumentation
or
they
may
be
suspicious
of
instrumentation.
That
was
provided
by
a
third
party,
for
example,
so
it's
possible
to
have
distributions
of
our
Java
agent
based
on
what
pile
of
software
it
actually
installs
for
you.
O
Yeah
I
I
mean
it
makes
sense
that
that
you
have
done
a
distribution
of
this
agent
versus
that
there's
still
under
question
like
what
is
part
in
general
of
this
Auto
instrumentation
right.
So
again,
if,
if
I
read
the
definition
of
auto
instrumentation,
it
only
says
something
along
the
lines
like
yeah.
This
is
instrumentation
for
your
application,
but
what
what
does
this
include
so
does
this
include
only
instrumentation
libraries
does
it
also
include
an
an
otlp
exporter
Does.
O
It
include
resource
detection,
which
is
also
some
kind
of
instrumentation
right,
I,
think
I
have
a
list
somewhere
up
there.
I
I
thought
about
a
few
things
or
Java
also
knows
the
concept
of
what
they
call
extensions.
Is
this
also
part
of
automatic
instrumentation,
or
is
this
already
distribution,
or
do
we
need
a
different
term
for
them?
O
Because
if
I,
if
I'm
in
the
documentation
and
I
try
to
describe
those
things,
then
then
it
would
always
be
good
to
have
at
least
a
little
bit
of
consistency,
if
not
I
have
to
say
like
in.net.
We
call
this
thing
this
in
that
way.
In
Java
we
call
it
agent,
but
we
don't
use
this
term
here
here.
We
use
something
different,
so
this
this
is
where
this
is
coming
from.
J
Yeah
it's
and
it's
it's
made
muddier
by
by
marketing,
so
you
you
can
go
read
about
like
Go
Auto
instrumentation,
which
is
just
manually
installed,
instrumentation,
so
I,
don't
I
I,
don't
know
how
strictly
I
wanted
to
find
that
term.
But
if,
if
we
were
to
Define
it
for
our
project,
I
would
try
to
say
Auto.
Instrumentation
is
a
technique.
That's
a
mechanism
for
installing
packages,
the
question
of
which
packages
are
you
detecting
and
installing
that's
a
distribution.
It's
the
set
of
packages
that
you
are
installing
through
some
mechanism.
J
That
mechanism
might
be
an
installer.
It
might
be
an
agent.
It
might
be
something
like
what's
being
done
in
Python,
where
it
reads
your
dependencies
and
then
you
know
adds
a
larger
set
of
dependencies
to
your
dependency
list.
J
O
So
we
now
have
those
projects
called
right:
language,
slash
instrumentation
and
we
have
it
for
java.net
and
I
think
now
also
PHP
and
go.
But
if
we
look
at
Java
and
net
right,
I
mean
they're
moving
a
little
bit
more
towards
that
direction,
that
they
say
like
hey.
We
have
this
all-in-one
solution
for
you,
then
then
you
would
call
that
a
distribution.
J
The
Java
agent
is
an
auto
instrumentation
mechanism,
it's
an
installation
mechanism
and
you
we
provide
a
community
distribution
of
the
Java
agent.
That
has,
you
can
go,
see
the
list
of
things
it
will
install
for
you,
but
it's
totally
possible
to
bundle
up
our
our
agent
mechanism
with
a
different
list
of
instrumentation
I.
Don't
think
we
provide
tooling,
for
that
necessarily,
and
the
same
thing
goes
for
The
Collector
right
like
for
the
collector.
We
provide
several
different
distros.
J
One
is
like
a
very
tiny
footprint,
District
of
The
Collector
that
has
just
the
the
minimal
set
of
plugins
in
it,
and
then
we
have
a
sort
of
kitchen
sink
distro
of
The
Collector.
That's
everything
in
collector
contrib
compiled
into
it,
and
then
we
have
tooling
to
allow
people
to
build
their
own
collector
distro,
with
whatever
subset
of
plugins
or
proprietary,
plugins
or
or
third-party
plugins
they've
written
themselves.
O
Yeah
can
I
mean
can
can
we
can
we
continue,
then?
Maybe
this
discussion
on
a
ticket
so
that
that
we
didn't
can
use
this
reference.
So
I
said
My
ultimate
goal
is
have
some
kind
of
consistency,
especially
also
across
the
documentation.
O
So
so,
if
you
can
settle
on
something
like
that,
where
we
say
like
distribution
means
exactly
what
you
said-
and
this
is
the
differences
of
that
that
that
would
be
highly
helpful.
Okay.