►
From YouTube: 2021-12-01 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
C
Not
too
much,
I'm
still
in
progress
of
like
completing
the
the
pull
request
for
scope
and
roadmap.
I
got
really
useful
comment
from
people
from
yuri's
guru
and,
like
I
rephrased
a
couple
of
things
waiting
for
another
iteration
of
review.
C
A
A
A
Cool
looks
like
nobody's
there.
I
guess
we
don't
have
lumila
today
and
robert.
Is
this
your
your
first
time
coming
to
these
meetings?
Am
I
spacing
out
on
that.
A
Okay,
there
was
someone
who's,
saying,
they're
gonna
be
showing
up
here.
So
I
wasn't.
I
wasn't
sure
if
that
was
you.
B
A
So
we're
kind
of
coming
to
the
the
end
of
the
year.
Here
I'm
gonna
be
out
for
the
rest
of
the
year,
just
fyi
I'll
be
back
in
january.
A
I
thought
it
might
be
helpful
to
go
over
q1
goals,
and
I
think
this
you
know
obviously
relates
to
the
road
map
that
you've
been
putting
together,
but
it
would
be
helpful
to
understand,
like
we
have
goals
for
q1,
just
knowing
what
kind
of
like
people
power,
we
think
we'll
need
to
accomplish
those,
and
I
can
help
try
to
try
to
find
people
make
sure
we've.
We
actually
have
people
who
have
time
to
to
do
some
of
the
work.
A
And
I
see
someone
added
security
concerns
to
the
list
as
well.
Maybe
we
should
hit
that
up.
First
get
that
done,
get
that
discussed
and
then
we
can
spend
the
rest
of
our
time
just
thinking
about
how
to
game
plan
for
for
q1.
How
does
that
sound.
C
Yep
sounds
good,
so
actually
yeah,
that's
what's
topic
added
by
me.
So
let
me
share
my
screen.
Then
I
can
provide
you
more
context
so
still
struggling
like
I'm.
C
Yeah
great
so
yeah
it
was,
it
was
the
question
basically
came
up
one
hour
ago
by
james,
and
we
do
have
like
in
school
for
semantic
conventions.
Spec
we
won.
We
do
have
this
topic
for
security
concerns
and
basically
the
the
overall
problem
here
is
that
we
can
have
some
attributes
that
potentially
can
contain
some
sensitive
information
and
what
exactly?
How
exactly
we
want
to
address
this.
C
So
for
we
want
last
time
we
decided
that
we
just
can
kind
of
call
them
out
the
list
of
attributes,
so
people
will
be
explicitly
kind
of
notified
which
which
attributes
can
contain
this
information
and
then,
in
the
later
versions
of
this
specific
of
the
specification
we
can
find
out
like
how
exactly
we
want
to
deal
with
it,
but
the
the
question
that
we
have
today
actually
james,
proposing
to
move
it
out
out
of
like
a
wee
one
and
put
it
to
the
next
version
to
be
next
to
the
second
or
whatever
version
we're
going
to
have
just
because
this
is
like
a
wide
topic
and
definitely
we
need
to
think
carefully
about
it,
and
maybe
it
will
be
better
to
address
it
separately.
B
I
apologize
for
background
noise
nephew's
over
and
he's
wild.
We
actually
like
we've
seen
this
in
production,
like
with
the
hdb
target
containing
credentials
so
like.
I
think
this
is
super
relevant
and
super
important
to
potentially
have
it
figured
out,
but
I
don't
know
how
how
extensively
we
have
to
define
the
behavior
around
it,
but
yeah
like
we've,
had
like
users
report
like.
Oh,
this
credential
got
leaked
in
the
hdb
target
and
it's
like
this
is
not
good.
B
A
Yeah,
so,
as
far
as
like
you
know
there
being
like
v1
or
v
v,
next
and
whatnot-
I
guess
I
agree.
This
could
be
v
next,
in
the
sense
that
figuring
out
how
to
deal
with
this
stuff
doesn't
doesn't
affect
any
of
the
the
the
rest
of
the
the
v1
work.
A
In
other
words,
there
isn't
stuff
that
builds
on
top
of
this
work.
So
in
that
sense,
I'm
like
okay
yeah.
This
could
be
done
in
a
subsequent
iteration,
just
just
purely
from
that
that
sense.
If
that
makes
sense,
it's
not
like
we're
going
to
figure
out
we're
going
to
identify
everything
that
needs
to
be
scrubbed
and
a
scrubbing
mechanism
and
then
be
like.
A
Oh,
this
totally
affects
defining
semantic
conventions
or
retries
and
redirects
or
or
span
collapsing,
or
any
of
that,
like
other
core
work,
but
at
the
same
time
it
seems
like
at
least
identifying
where
we
think
there
is
a
security
concern
seems
like
critical,
like
I
I
feel
like.
I
wouldn't
want
to
delay
that
part.
C
Yeah,
it
is-
and
I
I
think,
that's
for
yeah,
so
that's
why?
Actually,
I
included
this
this
topic
here,
but
in
the
same
time
like
at
the
way
how
we
currently,
you
know,
work
with
semantic
conventions,
doc,
and
we
do
have
this
yaml
thing
and
data
model
and
and
other
things
right.
So
it
was
another
conversation
on
the
same
topic
here
that
we
probably
can
extend
this
data
model
adding
some
another
attributes.
C
So
even
even
you
know
even
to
call
out
these
attributes
that
potentially
can't
contain
sensitive
information-
st
it
is
still
some.
Some
amount
of
work
should
be
done
and
it
can
be
good
first
step,
but
the
thing
is:
that's
not
really
so,
probably
james
and
colby.
C
They
are
not
really
sure
that
it
will
be
possible
to
do
that
within
next
kind
of
three
months
or
something
so
from
from
this
perspective,
maybe
we
need
to
just
explicitly
move
it
out
of
scope,
for
we
want
and
just
think
about
it
more
in
the
same
time
frame
right.
So
we
can.
We
don't
need
to
postpone
this
work,
but
what
we
can
do
now
is
say
just
say:
that's,
okay.
C
This
is
something
that's
we
will
not
include
in
v1,
as
is
so
this
topic
kind
of
not
well
defined,
for
we
want,
and
I
I
totally
agree
that
this
something
can
be
done
kind
of
later,
so
it
will
not
change
the
overall
like
a
perception
of
how
we
see
so
many
conventions,
or
it
will
not
change
the
structure
of
spans
in
some
in
some
scenarios,
so
probably
something
that
we
can
just
iteratively
do
as
a
as
a
follow-up
work.
So
yeah.
C
That's
that's
why
I'm
actually
on
the
fence
about
this,
but
because
really
the
topic
is
really
wide
and
we
need
to
think
about
this
really
carefully
and
all
these
concerns
should
be
addressed
like
meaningfully,
but
from
the
other
side
it
will
take
some
time
so
right.
A
Maybe
a
way
of
phrasing
this
when
we're
talking
about
v1
here,
the
the
goal
is
being
able
to
declare
the
semantic
conventions
stable
for
http
right
right,
saying,
like
we
have
done
the
work
so
that
people
can
go,
write,
instrumentation
and
declare
that
instrumentation
stable
and
from
that
point
onwards
any
work.
We're
doing
is
not
going
to
affect
the
data
that
comes
out
of
open
telemetry
in
a
way
that
would
break
dashboards
or
anything
consuming
the
data
without
without
putting
in
a
version
control
mechanism
in
the
collector.
A
So,
ideally
one
like
we
don't
break
anything
after
this
point,
but
two.
If
we
do
make
some
kind
of
change
that
actually
changes
the
data
that
comes
out
of
open
telemetry
by
default,
we
would
need
to
add,
based
on
the
version,
schema
work.
That
tigran
has
done
add,
add
a
schema
versioning,
some
kind
to
to
the
collector
right,
so
that
you
would
be
able
to
load
up
new
instrumentation
but
transform
it
back
into
potentially
older
instrumentation
and
so
not
break
things.
A
But
one
thing
that
means
is
new:
data
that
comes
out
has
to
essentially
be
a
superset
of
the
data.
That's
already
in
there
right,
because
otherwise
there's
no
way
to
write
a
translation
mechanism.
If
it's
we
used
to
emit
some
data
and
then
we
dropped
that
data
in
the
new
version
of
the
instrumentation.
A
So
the
only
way
that
to
me
really
affects
security,
I
guess
is
if
we
decided
these
are
the
semantic
conventions,
we're
going
to
admit
and
then
later
came
back
and
said.
Actually
this
is
a
big
security
concern
like
we
should
not
emit
this
data
at
all,
because
that
would
be
breaking
stability
to
to
drop
an
attribute.
At
that
point,.
C
Yeah
that
that
makes
a
lot
of
sense
actually
and
yeah.
The
thing
is
that
probably
we
still
want
to
emit
these
http
targets
right.
So
the
question
here
is
like
a
not
about
like
a
meeting
or
not
emitting,
but
it
is
more
about
the
mechanism
that
we
might
want
to
introduce
going
forward
to.
Actually
you
know
kind
of
sanitize,
this
data
or
scrub.
C
This
data
so
and
looks
like
we
still
need
to
these
targets
to
be
present
anyway,
because
it's
it's
something
which
is
important
for
for
customers,
but
at
the
same
time
it
has
this
security
concept
concern
and
can
contain
potentially
contain
sensitive
information
like
credentials
or
some
pii,
and
from
this
perspective,
for
we
want,
we
agree
that
it
might
be
useful.
Just
for
now
came
up
can
come
up
with
some.
You
know
set
of
attributes
and
explicitly
call
them
outs
and
say
that
okay,
so
these
these
are.
C
This
can
contain
this
information,
but
since
we
we
are
still
kind
of
unstable
in
these
points
it
might
be.
It
might
be
hard
to
do
that.
A
C
But
yeah,
so,
even
even
if
we
decide
now
that
we
want
to
call
them
out,
it
doesn't
probably
mean
that
for
we
next,
we
will
just
drop
this
this
data,
because
it's
still
important
right.
We
just
need
to
come
up
with
some
mechanism
to
actually
sanitize
or
clean
clean
this
data
or
remove,
remove
credentials
or
something
which
can
be
security,
concern.
A
Yeah
I'm
curious.
I
see
honorariux
on
the
call
who's
super
familiar
with
java,
auto
instrumentation,
which
already
has
at
least
for
sql
sanitization
mechanisms.
If
I'm
not
mistaken,
I'm
curious
honorable.
How
did
you
guys
approach
sql
sanitization?
A
D
A
You
know
people
can
disable
the
sanitation
if
they
don't
care
or
they
could
move
the
sanitization
out
to
a
collector
if
they
didn't
want
to
do
it
in
process,
for
example
like
doing
it
on
the
other
end
of
a
bunch
of
sampling
they
might
be
doing,
but
it
seems
like
on
by
default
would
be
good.
B
Yeah,
I
think
it
makes
a
lot
of
sense
like
we
we've
been
trying
to
move
towards
that
internally
in
our
like
company,
we're
shifting
a
little
bit
we're
going
to
make
the
default
for,
like
our
internal
configuration
to
just
be
omitting,
because
we
don't
want
to
potentially
just
like
pay
for
moving
all
that
information
around
if
nobody's
actually
consuming
it.
B
So
people
have
to
opt
in
and
then
by
default,
we'll
obfuscate
at
the
collectors
we
we're
moving
our
process,
but
for
the
repo
itself
we're
trying
to
make
it
consistent
that
it's
obviously
a
bit
default
just
to
kind
of
protect
the
users.
B
But
the
concern
is
the
performance
hit
on
on
doing
the
sanitization
right
like
we
are
concerned
about
that,
but
again,
like
I'm
kind
of
torn
between
making
like
dropping
it
by
default
and
letting
people
make
the
conscious
decision
that,
like
yes,
I
would
like
to
keep
it
plain
text
or
I
would
like
to
obfuscate
it
and
then
there
at
least
they're
aware.
So
it
puts
a
little
bit
of
like
bonus
on
the
user
to
make
sure
that
they
know
what
they're
getting
into
and
they
don't.
Just
like.
B
B
A
The
the
problem
with
I
just
would
add
the
problem
with
not
emitting
data
by
default
because
of
the
potential
overhead
is
users
new
users.
Don't
they
don't
know
that
the
data
is
there,
so
we've
I've
actually
found
that
to
be
like,
like
kind
of
a
poor
default
like
like
it's
better.
I
found
that
users
get
more
familiar
with
tracing
if
the
default
is
like
give
them
all
the
information
and
then
let
them
be
like
this
is
noisy
or
expensive.
I
want
to
want
to
dial
it
back
so.
A
B
Yeah,
I
agree
I
think,
like
us
internally.
Hiding
it
by
default
is
a
very
opinionated
choice
and
like
we're
going
to
have
like
onboarding
documentation
around
like
this,
but
for
for
the
open
source
defaults.
We
do
want
to
shift
everything
to
obfuscate
by
default,
and
it
just
it.
It
seems
like
the
potentially
the
best
option,
even
knowing
that
you
might
like
have
a
performance
set
on
it,
especially
like
ruby
right,
yeah.
D
I
think
sql
is
easier
to
sanitize.
That's
one
thing,
because
it
has
a
grammar
like
a
url,
you
don't
know
which
part
of
the
path
is
actually
sensitive.
It
could
be
any
part
of
the
path,
and
so
I
don't
know
if
there's
even
a
way
to
sanitize
the
url
by
default,
not
without
the
user,
providing
a
pattern
of
some
sort
so
like
there
will
be
these
flags.
All
we
can
really
do
is
call
out
that
they
might
have
sensitive
check
what
path
you're
using
and
maybe
specifying
the
config.
C
Yeah
actually
yeah.
I
tried
to
do
this
like
previously
a
couple
of
times
for
microsoft
services
and
it's
really
really.
C
Something
which
can
be
done,
which
will
not
hit,
which
will
not
impact
performance
significantly,
is
just
remove
or
redact
everything
which
is
which
is
path
just
just
like
a
having
a
hostname
and
some
string
that
you
find
that
the
overall
like
a
pass
and
query
string
were
rejected
so
like
yeah
automatically,
it's
really
hard
to
do
so,
but
just
I
also
wanted
to
mention
that
at
least
for
that
nets-
and
we
have
two
sdks
for
that
net,
like
open,
telemetry
and
application
in
size,
sdk
and
both
of
them
by
default.
C
Already
now
like
they
are
emitting
this
data.
So
it's
already
there
and
I
it
may
be
the
same
for
other
languages
as
well,
so
for
all
all
other
http
instrumentation
build
the
auto
instrumentation
or
just
instrumentation
libraries.
C
I
believe
this
http
target
is
already
something
which
is
which
we
sent
to
back-end,
and
it's
already
it's
already
there
and
seems
it.
It
will
be
there
so
yeah
that
that's
might
be
reasonable,
just
to
call
call
this
out
for
everyone,
but
actually
what
exactly
should
be
done?
Is
it's
really
really
unclear
at
this
moment
for
me
so
like
how
how
exactly
we
want
to
address
this
problem,
which
kind
of
configuration
language
we
want
to
provide
how
to
mark
as
part
of
the
http
targets?
C
That's
all
this
should
be
redacted.
This
is
not
really
clear
at
this
point
so
but
yeah,
but
the
question
is
like:
do
we
want
to
move
the
the
whole
like
the
whole
topic
out
of
b1,
or
just
have
these
parts
done
for
v1
and
the
other
parts
done
for
the
next.
B
B
But
then,
if
we
try
to
rope
in
discussion
around
like
control
mechanisms
like
for
an
application
owner
that
has
their
own
collector
and
they
can
add
their
own
spam
processors
to
clean
up
or
whatever,
to
manipulate
the
data
after
the
fact,
I
think,
like
they
have
a
nice
advantage
that
they
don't
have
to
worry
necessarily
about
the
instrumentation
supporting,
maybe
finer
grain
controls
on
it,
because
they
can
just
control
it
after
the
fact,
but
for
people
who
don't
have
that
control
like
what?
B
A
That
that's
a
big
can
of
of
worms
that
I
I
do
think
is
is
interesting.
It
just
gets
into
like
there's
like
two.
The
problem
with
that
is
that
there's
two
ways
to
do
it.
One
is
general
purpose,
basically
doing
what
you
do
in
the
collector.
So
right
now,
if
you
want
to
do
that
kind
of
stuff,
you
can
just
do
it
in
the
collector.
So
we
do
have
like
an
easy
answer
right
now,
which
is
to
say,
you
know,
run
a
collector
and
you
can
do
that
stuff.
A
Of
course,
a
bunch
of
people
can
come
back
and
say
like
no.
No,
no,
I
don't
want
to
run
a
collector,
or
you
know
we
have
a
requirement
that
we
just
can't
admit
this
stuff
at
all,
and
the
the
problem
with
doing
that
in
process
is
either.
A
A
You
know
spam
manipulation
stuff
with
like
a
configuration
language
like
the
collector
has
or
every
piece
of
instrumentation
you
install,
starts
to
develop
its
own
configuration
language
and
when
you
write
instrumentation
you're
doing
a
bunch
of
you
know
configuration
you
know,
which
one
means
you're,
adding
a
bunch
of
switch
statements
everywhere,
but
two
also
makes
makes
setup
more
difficult.
This
is
the
thing
we
found
with
open.
Tracing
open
tracing
basically
took
that
route.
A
Where
you
know
we
just
had
a
big
pile
of
contrib
instrumentation
and
what
people
would
do
is
they
would
go
to
each
instrumentation
repo
and
be
like.
Can
you
add
a
configuration
option
for
blah
and
a
lot
of
those
options
were
about
suppressing
or
adding
information?
You
know
or
changing
the
way
something
was
reported,
which
is
fine,
but
then
it's
like
when
you're
actually
trying
to
like
set
up
and
manage
a
big
system
you
now
have
like
ever.
A
You
have
to
look
at
like
every
instrumentation
package
to
see
how
to
configure
that
thing,
and
then
you
have
to
actually
be
able
to
go
and
configure
it,
which
means,
generally
speaking,
changing
things
and
process
where
it
means
instrumentation
is
starting
to
grab
at
your
environment,
variables
and
stuff
and
like
that,
all
of
that
seemed
bad
at
scale.
A
So
I
would
love.
However,
we
end
up
tackling
configuration
for
instrumentation
like
like
in
general.
I
would
love
that
to
be
part
of
like
open
telemetry,
moving
towards
having
just
like
a
configuration
file
with
some
kind
of
standard
way
of
doing
this
stuff,
so
that
you
could
just
put
all
of
your
configuration
in
one
place,
and
there
was
some
some
kind
of
regularity
around
how
we
did
it
so
so.
A
B
I
think
I
think,
that's
totally
fair
to
like
kind
of
circle
back
to
like
hdb
target,
like
I
think,
with
everything
you
added
like
the
context
of
open
tracing,
because
I'm
not
really
familiar
with
like
what
that
story
was
like
there.
I
think
it
makes
sense
to
include
this
information.
I
think
it's
much
less
painful
overall
than
omitting
it,
and
I
think
people
really
will
come
to
expect
it.
I
think
highlighting
it
as
a
security
concern
and
literally
just
flagging.
B
It
is
probably
sufficient
to
say:
hey,
like
this
field,
sometimes
contains
sensitive
information,
be
careful
or
whatever,
but
that
other
can
of
worms
is
actually.
I
think
why
I
started
coming
to
these
meetings
is
hoping
to
see
what
unfolds
there,
because
I
am
very
interested
to
see
how
we
define
pulling
a
configuration
for
instrumentation
like
I
not
as
part
of
v1.
B
I
think
it
would
be
interesting
to
see
if
there
is
configuring
configuration
options
for
http
spec
like
it
becomes
part
of
the
spec
like
your
http
instrumentation,
contains
these
configuration
options,
and
these
are
how
you
can
set
them,
and
then
you
obviously
have
some
formal
definition
that
different
languages
would
adhere
to,
but
like
that,
coming
out
of
a
v1
seems
like
overly
like
that's
too
ambitious.
I
think.
A
That
that
was
kind
of
what
we
decided
if
v1
is
really
just
like
look.
We
want
to
ship
stable
instrumentation
like
we
just
want
to
declare
this
stuff
stable,
and
that
doesn't
mean
you'll
be
happy
with
it
right,
like
you're,
going
to
still
want
to
modify
it,
but
generally
the
way
you're
going
to
want
to
modify.
It
is
like
turning
stuff
off
right,
you're
going
to
want
to
drop
attributes
you're
going
to
want
to
drop,
noisy
traces,
noisy
spans.
That's,
like
the
other,
really
common
thing.
A
People
want
to
drop
and
right
now
we
have
like
a
really
robust,
well
thought
out
way
of
doing
all
of
that,
which
is
the
collector.
That's
the
place
where
we've
actually
like
put
a
lot
of
thought
into
how
you
do
that
stuff,
but
we
don't
even
have
like
a
configuration
file
for
the
sdks
yet
and
so
like
right
now,
open
telemetry
sdks
are
like
just
getting
buried
under
a
pile
of
poorly
thought
out
environment
variables.
A
A
But
I
think
like
for
this,
this
group,
like
what
I
think
we
should
do,
is
just
like
like
get
get
this
instrumentation
stable
and
then
kind
of
like
plug
into
that
configuration
work
as
it
as
it
comes
along,
rather
than
kind
of
like
in
parallel
start
trying
to,
like.
A
You
know
tack
on
a
lot
of
a
lot
of
configuration
stuff
because,
because
it
just
it
shows
up,
left
and
right,
like
sampling,
is
the
other
place
where
people
will
pop
in
and
be
like.
I
want
to.
I
want
to
do
like
sampling,
where
I
I
drop
noisy
spans.
C
Yes,
exactly
so
like
this
configuration,
I
think
we
already
kind
of
had
a
couple
of
discussions
on
this
and
that's
exactly
what
we
also
want
for
error
status
right,
because
we
also
like
I
want
to
define
what
is
the
error?
What
is
not
for
some
particular
application
and
the
same
yeah
the
same
for
sampling.
Basically,
it
might
be
useful
to
have
it's
enabled
disabled
or
like
have
some
hints
here
and
yeah
this
configuration
topic.
C
Actually
I
have
this
like
open,
telemetry,
general
kind
of
open
questions,
and
this
is
this
is
exactly
what
it
is
right
so
like
how
the
this
configuration
language
should
look
like.
Should
it
be
filed,
should
it
be
some
dsl
or
or
whatnot
right
yeah.
C
Definitely
it's
out
of
scope
for
v1
and
actually
out
of
scope
for
http
semantic
conventions,
because
applicable,
for,
I
believe,
all
of
all
semantic
conventions
right
yeah,
but
like
to
be
able
to
declare
https
of
any
convention
stable,
like
a,
I
believe
so
like
should
we
should
we
should
we
call
out
these
attributes
or
not
so
yeah
during
the
like
in
the
beginning
of
discussion,
I
had
this
like
a
opinion
that
it
might
want
to
postpone
it
like
to
move
it
to
me
next,
but
looks
like
we
still
need
it
right
so
to
declare
it
as
a
stable.
C
A
A
This
stuff
is
to
write
scrubbers
in
the
collector
right
so
contribute
if
people
can
contribute
algorithms
for
for
scrubbing
the
stuff,
it
sounds
like
we
have
them,
then
we
can.
We
can
at
least
get
that
stuff
there.
A
A
We
don't
yet
have
like
a
way
of
like
configuring
all
of
that
stuff
in
every
piece
of
instrumentation.
We
don't
need
to
do
that
to
call
things
stable,
because
that's
a
lot
more
work
than
just
identifying.
What's
what
needs
to
be
scrubbed
and
adding
a
scrubber
to
the
collector
right?
Like
that's,
that's
some
amount
of
work,
but
it's
way
way
less
work.
C
But
to
to
be,
you
know
to
be
like
it
will
be
good
since,
like
it
will
be
good
to
be
explicit,
what
exactly
they
need
to
put
it
and
put
their
attention
on
so
yeah.
It
looks
like
really
reasonable
and
yeah.
I
agree
that,
might
it
might
like
a
bit
better
to
to
have
it
for
v1.
D
All
right
just
for
reference,
I
sent
a
link
and
zoom
to
the
design.
I've
been
working
on
with
the
collector
folks
about
processing
there.
Maybe
the
one
line
is
the
most
relevant
for
sanitization
purposes.
D
D
If
you
want
to
search
for
that,
but
yeah
like
while
writing
this,
I
sort
of
imagined
it
would
first
be
in
the
collector
and
then,
if
sdks
want
to
offer
this
functionality,
they
could
probably
still
use
the
same
language
at
some
point
and
of
course
that
will
be
at
some
point
and
for
some
languages,
maybe
not
ever.
If
it's
just
not
a
priority
for
those
languages
but
yeah,
we
could
still
have
that
consistent
language
between
the
collector
and
the
sdks.
A
C
Definitely
yeah,
if
you
have
one,
if
we
have
some
languages,
probably
it
will
be,
it
should
be
one.
We
can
use
in
many
many
places
like
in
broads
and
now
for
us.
A
C
Actually,
we
already
have
this
topic
included
to
do
the
proposal,
so,
like
a
4v1,
we
previously
agreed
that
we
want
to
identify
these
attributes.
I
call
the
number
I'll
call
them
out
explicitly
but
yeah.
This
was
just
conversation
and
I
will
I
will
post
a
reply
to
this
conversation
based
on
what
we
just
decided.
A
Okay,
so
I
think
this
dovetails
nicely
with
what
what
I
would
like
to
talk
about,
which
is
kind
of
getting
into
like
the
the
brass
tacks
about
the
the
v1
scope.
A
A
I
feel
like
there's
some
some,
maybe
like
practical
matters
of
then
actually
implementing
all
of
this
stuff
that
aren't
currently
in
the
the
road
map,
and
I
was
wondering
if
we
could
maybe
just
do
like
a
if
we
could
just
maybe
quickly
as
a
group
build
out
a
list
of
like
if
we
were
to
declare
this
stuff
stable
and
then
go
and
implement
it
like
what?
A
Do
we
want
like
an
instrument
or
object
http
instrument
or
object
in
different
languages
like
we
have
in
java?
Do
we
need
some
kind
of
testing
testing
harness
to
help
ensure
that
the
instrumentation,
we're
writing
is
correct?
A
We
need
to
to
do
an
audit
of,
like
literally,
what
is
all
the
instrumentation
that
we
have,
that
we
need
to
to
then
go
and
update,
and
then
we
need
to
like
have
people
actually
go
and
update
that
stuff
and
also
maybe,
as
part
of
that
sort
out,
ownership
of
those
different
contrib
libraries
like
those
instrumentation
packages.
A
I
think
some
of
them
may
have
like
owners
who
are
active,
but
a
number
of
them,
I
think,
were
basically
like
donated
once
like,
for
example,
a
bunch
of
data
dog
donated
instrumentation,
meaning
they
said
you
could
have
it
and
like
a
pile
of
people,
kind
of
like
thunked
it
over
to
open
telemetry
at
one
point.
But
then
it
kind
of
just
became
the
core
maintainers
problem
in
those
languages
for
maintaining
it
and
they
feel
in
general.
A
The
core
maintainers
feel
like
they
don't
have
like
enough
bandwidth
to
also
maintain
all
the
instrumentation
like
java's
in,
like
a
really
good
shape
right
now,
because
in
addition
to
core
maintainers
there's
also
the
like
auto
instrumentation
maintainers,
who
you
know
like
really
focus
on
that
stuff.
But
in
a
lot
of
other
languages
like
that,
there
isn't
really
a
a
concrete
group
that
that
focuses
on
that
stuff.
A
So
it
just
feels
like
there's
a
besides
just
defining
this
stuff
in
this
spec
and
declaring
it
stable.
There's
there's
some
like
additional
work.
We
got
to
do
and
I
would
love
to
see
an
ideal
world
that
we
we
get
get
all
that
done
in
in
q1,
or
at
least
we've
declared
everything
stable
in
the
spec
and
we're.
You
know
well
on
our
way
to
to
getting
everything
implemented
by
the
end
of
q1.
A
It
feels
doable,
but
it
I
think
it's
only
doable
if
we
actually
like
have
people
who
have
decided
to
pitch
in
and
help
do
it
and
the
only
way
we'll
get
those
people
is.
If
we
can
like
write
down
what
what
all
the
things
are
that
need
to
get
done,
then
it's
a
little
bit
easier
to
find
people
who
can
say,
like
oh
yeah,
I'll
help
do
that.
C
C
We
do
have
like
a
we
want
for
the
first
table
version.
Currently
we
do.
We
captured
like
a
five
items
right
so
like
error
status,
which
is
really
really
simple,
so
we
can
do
it
almost
right
away
and
we
do
have
this
retries
and
redirect
stuff
and
I'm
working
on
it.
I'm
I
will
be
so
yeah.
We
have
a
lot
of
promising
results
or
we
have
implementation
for
that
and
for
java.
C
So
and
basically
the
next
step
will
be
to
contribute
to
data
implementation
right
and
make
it
kind
of
default
for
nets
and,
in
the
same
time,
included
to
the
specification.
So
it
will
be,
it
will
be
there
so
and
context
propagation
actually
falls
to
the
same
bucket.
So
it's
really
close
to
the
like
a
retries
and
redirects
and
the
way
how
it
exactly
can
be
done,
and
this
this
actually
is
more
about
kind
of
guidance.
C
How
you
want
to
you
know,
implement
this
retries
and
redirect
stuff,
and
maybe
similar
scenarios
in
different
implementation,
libraries
and
basically,
two
more
like
or
like
a
two
big
things
that
we
have
here
are
the
security
concerns
thing
that
we
just
discussed
and
looks
like
we
have
a
direction
here,
so
it's
just
it
shouldn't,
be
it
shouldn't
be
really
time
consuming
to
do
that
right.
C
It
just
just
just
about
in
like
identifying
these
attributes
and
mark
them
properly,
like
just
have
another
column
in
the
or
another
like
a
column
in
the
in
the
in
the
table,
and
another
thing
is
required
attribute
sets
like
what
exactly
should
be.
We
should
put
as
required
from
the
client
and
server
side
so
currently
in
the
in
the
current
version
of
specification.
C
There
is
no
like
a
differentiation
between
client
and
service
from
this
perspective,
and
but
it
will
be
good
to
you
know,
make
it
make
it
so
so
we
can,
we
can
define
that
this
is.
This
is
a
required
attribute
for
client,
and
this
set
of
attributes
is
only
required
for
server
and
it
seems
it's
really
doable
and
yeah.
C
We
do
I
I
actually
james
in
from
from
atlas,
and
probably
he
asked
this
question
last
week
like
what
exactly
should
be
done
to
make
it
stable
like
do
you
guys
need
any
help
and
these
two
topics?
I
also
posted
these
two
topics
there.
So
from
from
this
perspective,
I
believe
that
we
have
like
a
two
topics,
almost
covered
one,
one,
easy
topic
and
two
two
topics
that
folks
can
help
with.
C
Yeah,
so
let
me
let
me
share
my
screen
just
to
show
it,
so
it
will
be
easy
to
follow
up
so
here
it
is
all
right,
so
yeah,
as
I
mentioned,
we
do.
We
do
have
this
error.
This
is
which
is
easy,
which
is
easy,
so
the
first
like
a
big
one
is
required,
attribute
sets.
So,
for
example,
we
can
declare
that
for
client
this
this
should
be
only
required
and
for
service
for
server.
These
three
should
only
be
required.
C
Others
we
can
just
declare
as
as
optional
that
we
do
now
or
maybe
maybe
remove
them
completely
just
because
it
makes
additional
kind
of
noise.
So
yeah,
that's
something
that
we
can
figure
out
there.
So
this
topic
is
is
in
progress,
and
I
expect
it
will
be.
It
will
be
resolved.
This
one
is
really
close
to
this
one
and
the
last
one
is
security
concerns.
So
that's
exactly
what
we
were
talking
previously
yeah.
A
So
identify
security
concerns
separating
the
required
attributes
out
into
client
and
server.
There
is
one
item.
That's
I
think,
missing
from
here.
That's
relevant
to
instrumentation,
which
is
the
collapsing
instrumentation
work,
slash
debate
that
ludmilla's
been
leading
where,
if
you
have
several
layers
of
instrumentation
like
I
guess
this
thing
seems
to
come
up
in
java,
more
than
other
places
where
you
might
end
up
with.
A
C
Yeah
it
is,
but
from
from
my
perspective,
this
this
topic
was
kind
of
solved
already.
Maybe
I'm
missing
something,
but
you
know
it
was
a
long
discussion.
What
should
be
must
what
should
be
shoot,
and
that
was
a
part
of
that
discussion,
or
maybe
I'm
I'm
missing
this
okay.
So
maybe
it
will
be
good
to
follow
up
with
me
about
this
and
also
include
this
item.
A
C
A
If
you
you
end
up
with
what
looks
like
just
like
a
stack
of
like
http
client
spans
like
two
or
three
deep,
that
all
have
the
same
information
on
it
or
almost
the
same
information,
because
you
actually
have
three
separate
pieces
of
instrumentation
that
are
all
making
a
span
to
track
that
http
span.
We
we
got
rid
of
some
of
this
nonsense
through
the
dealing
with
the
retries
and
redirects
and
saying
like
look,
we
don't.
A
A
A
I
mean,
I
guess
on
some
level,
you
wouldn't
need
that
to
declare
instrumentation
stable,
because
that's
just
more
about
like
like
we're
the
instrumentation
you're
gonna
get
is
gonna,
be
stable.
The
question
is,
will
you
just
get
one
set
of
it
or
will
you
receive
it
in
triplicate
in
some
cases,
because
you
had
some
pluggable
nonsense
going
on
in
some
of
these
some
of
these
libraries
you
were
using.
B
I
always
kind
of
imagine
that
fit
more
into
like
we
were
discussing
earlier
is
like
it's
part
of
that
configuration
story.
Right
like
you,
have
these
duplicates
and
then
you
set
up
your
configuration
in
such
a
way
that
doesn't
so
like.
I
think
that
conversation
falls
more
into
like
yeah
configuration,
because
it's
like
I've
added
all
the
instrumentation
in
the
world
and
now
I'm
getting
duplicates.
How
do
I
handle
this.
C
Okay
yeah:
this
is
reasonable,
so
actually
yeah.
I
just
asked
this
this
question
to
ludmilla.
Maybe
she
will
she
can
come
up
with
some
additional
input
here,
but
yeah
it's
like
a
as
it
said,
maybe
for
we
want.
We
can
declare
that
we
want
to
like
you
know,
emit
everything
we
want
or
we
can
and
then
for
for
subsequent
versions.
We
can
decide
if
we
want
to
suppress
something
or
remove
something
or
reduct
something
or
sanitize
something.
A
C
Yeah,
definitely
that
that's
a
really
good
idea,
so
I
will
add
this
topic
for
we
next,
so
I
will
also
try
to
follow
up
about
this
with
milan
and
if
she,
if
she's,
okay
with
this,
I
will
add
this
topic
for
v
next
and
like
how
we
want
to
exactly
implement
this
suppression.
A
A
Great
okay
and
so
going
back
to
the
the
meeting
notes.
The
road
map
that
you've
got
together
currently
covers,
like
all
the
spec
work
we
have
to
do,
but
I'd
love
to
just
go
over
a
list
of.
Besides
that
spec
work.
Let's
say
we
declare
all
that
stuff
stable,
which
would
finish
out
the
v1
roadmap
in
that
that
dock
you
have.
We
would
then
have
to
go,
implement
this
stuff,
and
so
it
would
be
great
to
just
do
a
quick
review
of
like
what
what
we
think
we
we
need
or
would
be.
A
It
would
be
nice
to
actually
go
implement
all
this
stuff,
so
we
don't
just
have
stable
spec.
We
also
have
like
stable
instrumentation
packages.
We've
talked
about
this
in
prior
meetings.
I
just
thought
it
would
be
great
to
capture
that
in
the
in
the
notes,
which
I
don't
think
I
don't
think
we
did
when
we
talked
about
it
the
last
time
and
maybe
include
this
in
the
in
the
roadmap
as
well,
though
I
don't
know
if
you
want
to
keep
the
that
road
map
dock
to
be
just
the
spec.
A
You
know,
I
guess
that's
fine,
but
so
the
first
thing
that
comes
to
mind,
maybe
I
can
just
share
my
screen,
while
I'm
yapping
about
this.
A
So
we've
got
the
implementation
roadmap.
I
think
one
thing
we
identified
was
like
a
current
list
of
instrumentation.
A
So,
just
just
audit:
what
what
do
we?
What
do
we
currently
got?
What
do
we
have
to
update?
Then
it's
identify
rib.
B
A
So
we're
going
to
want
to
do
kind
of
just
like
a
call
to
action
in
all
the
different
languages
to
find
people
to
just
help
us
push
this
stuff
over
the
finish
line,
so
contributors
contribute
maintainers,
then
to
actually
go.
Do
this
like
what
kind
of
tooling
like
we
don't
technically
need
tooling
to
do
it.
You
can
just
go,
do
it
with
whatever
those,
whatever
the
api
packages
in
those
languages
currently
provide,
which
are
basically,
you
know
the
api
and
then
a
pile
of
constants
that
need
to
get
updated.
A
Actually,
that's,
I
think
we
should
add
here,
which
is
update
api
packages
to
match
spec.
A
B
Yeah,
like
I
like
the
test
harness
because
it's
like
you
define
like
a
set
of
tests
that
are
expected
to
pass
if
you
want
to
consider
your
instrumentation
stable.
So
if,
like
me
as
a
maintainer,
it's
like
okay.
I
want
to
make
sure
all
these
http
libraries
that
I
wrote
are
to
spec.
I
pretty
much
I'm
going
to
copy
the
test
across
all
of
them
or
reuse
it
whenever
and
just
make
sure
that
hey
yeah.
I
can
assert
that
this
is
actually
behaving
correctly.
D
I'd,
really
like
hotel
to
have
a
black
box
testing
framework
that
can
be
shared
across
all
the
languages
because
it
should
be
possible.
We
have
the
same
conventions,
you'll
need
some
tweaking.
It
can't
be
just
100
the
same
configuration,
but
with
some
sort
of
tweaking
of
the
templates.
I
think
we
can
have
pretty
good
black
box
testing.
Also.
C
Yeah
yeah-
and
I
I
also
really
like
this
idea
so
like
once
we
have
these
tests
implemented.
We
can
just
implement
them
using
just
single
language.
It
shouldn't
be
implemented
many
different
times,
but
we
as
a
as
this
blackpost
blackbox
testing
engine.
We
can
use
it
for
all
other
instrumentation
libraries
just
to
execute
tests
against
them,
so
that
that's
why
we
can
say
that
okay.
C
So
this
is
like
a
100
percent
coverage
and
this
is
like
87
or
something
so
it
will
be
really
really
helpful
for
us
and
for
community
for
all
our
other
customers.
Just
to
see
like
a
like,
a
which
part
percent
of
the
of
the
instrumentation
library
is
corresponds
to
the
current
or
to
the
next
version
of
semantic
conventions,
really
useful.
A
So
someone
I
forgot
to
someone
did
express
some
interest
in
working
on
test
harness
in
prior
meetings,
I'm
just
basing
on
who
that
is.
D
I
might
have
said
that
because
it's
basically
like
we
like
I've,
always
found
our
testing
framework
in
java.
It's
just
executing
his
cheap
request
and
checking
otlp.
So
there's
absolutely
nothing
java
about
that
yeah.
So
I've
always
wanted
to
move
that
out
into
a
separate
process,
so
I've
been
q1.
I
think
I'd
be
able
to
help
with
this
for
sure
not
this
year.
A
B
A
A
A
Besides,
just
the
the
test
harness
itself,
it's
just
what,
besides
what's
in
the
core
api
today
like
what
can
be
added
that
actually
makes
writing
this.
Instrumentation,
simpler
and
honorable's
done
a
great
job
of
implementing
a
version
of
this
for
java,
which
is
just
an
object
that
basically
changes
it.
A
As
we
add
metrics
and
other
stuff
on
there
right,
like
there's,
there's
just
going
to
be
more
and
more
data
that
we
want
to
emit
and
if
there's
like
one
centralized
place
to
to
do
all
of
that,
that
would
make
maintaining
a
bunch
of
instrumentation
libraries
easier
because
they
would
just
have
to
bump
their
dependency
on
on
this.
One
utility
object,
rather
than
going
back
through
and
making
sure
you're
now
admitting
all
the
right
metrics,
for
example.
A
If
we
add
it
it
because
if
we're
going
to
say
all
the
instrumentation
we're
writing
is
going
to
depend
on
it,
then
it
has
to
have
the
same
stability
same
level
of
stability
as
the
core
api.
A
Otherwise
we
lose
that
core
stability
we
work
so
hard
to
to
gain,
so
it
definitely
should
be
added
to
the
spec.
I
think
the
the
main
reason
we
haven't
yet
is
the
the
java
version,
which
is
no
offense
against.
A
It
is
very
feels
very
java,
flavored
to
other
people
who
have
looked
at
it,
and
so
we
literally
just
need
some
implementations
and
a
couple
different
languages
that
are,
you
know,
languages
that
are
fairly
different
from
java,
just
to
confirm
what
it
is
that
we
want
to
put
in
the
spec,
because
it
might
turn
out
it
might
turn
out
that
in
languages
like
go
or
python
that
have
very
different
type
systems,
for
example,
you
you
might
want
to
take
a
different
approach
to
how
you
do
it.
A
In
the
meantime,
we
need
to
make
sure
whatever
we're,
adding
still
stays
stays
stable,
but
I
would
like
that
work
to
be
coordinated,
not
just
every
language.
Sig
goes
off
in
a
corner
and
makes
a
pile
of
utility
functions,
but
even
if
they
do
that,
those
things
still
have
to
stay
stable.
So
just
for
clarity,
even
if
later
we
add
a
thing
to
the
spec.
That's
like
super
duper
instrument
or
object,
and
a
language
like
well,
we
already
implemented
a
thing.
That's
cool
that
language
can
keep
that
thing.
A
They
have
to
keep
that
thing
stable
and
then,
maybe
also
add
the
thing
in
the
spec,
but
they
wouldn't
they
wouldn't
mutate.
The
thing
they
already
have
into
matching
the
thing
in
the
spec
and
then
break
the
thing
they
currently
have
we
need
to.
We
need
to
really
avoid
that
kind
of
mutation
at
the
api
level,
more
than
anywhere
else
in
the
project.
That's
the
place
where,
where
really
bad
things
happen,.
A
I
don't
I'm
sorry
if
I
am,
I
wasn't
intending
to
call
you
out.
B
A
Yeah
yeah
just
make
sure
that
things
stay
here.
Here's
why
it's
important,
because
this
kind
of
stuff
is
it's
not,
is
gonna
get
out
there
in
third-party
libraries
and
stuff
right,
and
so,
if
it's
the
kind
of
thing
where
you
can
end
up
with
a
version
conflict
where
you've
got
multiple
packages,
now
trying
to
pull
in
incompatible
versions
of
the
same
thing,
and
that
thing
is
like
baked
into
like
third-party
libraries
or
or
baked
into
instrumentation.
We
haven't
gotten
around
to
updating
and
stuff
like
that.
A
A
B
A
Immutability
immutability
is,
is
our
friend
not
literal
immutability,
but
if
it's
going
to
create
a
virgin
conflict,
just
make
it
a
different
package
so
that
you
don't
have
like,
so
you
just
don't
have
that
problem
of
like
everyone,
depending
on
incompatible
versions
of
the
same
package,
they're
just
depending
on
different
packages
and
like
life
goes
on
at
that
point,
but
you
know
at
the
same
time.
Obviously
you
can
create
more
surface
area.
A
Hemi
yeah!
You
can
create
more
surface
area
for
yourself.
So
that's
why
we
want
to
be
careful
careful
around
this
stuff.
Anyways,
I'm
just
preaching
at
this
point:
okay,
we're
over
time.
Is
there
anything
peop
anyone
else
can
think
of.
Besides
this
list
here
of
like
stuff,
we
actually
need
to
do
to
to
push
stable,
instrumentation
out
into
the
ecosystem.
C
Yeah,
it
seems
seems
reflecting
what
exactly
we
need
to
do.
The
only
thing
maybe
yeah
I
would.
I
would
keep
them
separated
from
the
spec
road
map,
because
yeah
we
have
some
several
things
here
which
are
not
really
about
the
spec.
But
it's
more
about
how
to
test
implementation,
for
example,
or
how
to
extend
api
and
so
on
so
yeah.
A
Yeah
cool
so
yeah
when
we
come
back
in
in
january
or
when
I
come
back
in
january.
I
will
help
push
this
over
the
finish
line.
Obviously,
people
want
to
keep
meeting
at
this
meeting.
I
won't
be
here,
but
you
all
can
continue
to
talk
amongst
yourselves.
Please
don't
let
me
not
being
here
to
prevent
progress
from
happening,
but
I
just
wanted
to
make
sure
that
with
this,
this
road
map
was
clear
before
I
went
on
break,
so
thank
you
all
for
walking
through
all
this
with
me.