►
From YouTube: 2023-02-13 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
C
Got
people
another
minute,
I'm
not
seeing
a
lot
of
updates
coming
in,
but
maybe
there
just
aren't
any.
E
C
A
Yeah,
that
was
the
monthly
release
for
February,
so
yeah.
It
was
kind
of
a
small
release,
but
please
check
it
out
and
actually
I
have
a
point
to
discuss
once
all
this
is
reported,
their
status.
F
C
Okay,
no
report
Backs
from
logs
or
Proto
or
PHP,
or
no
updates
from
HP,
rather
Java,
how
things
going.
G
We
released
version
1.23
of
our
SDK
on
Friday
and
we're
going
to
be
releasing
similar
the
same
version
of
instrumentation
and
contribute
this
week.
No
other
updates.
C
Cool,
no
news
is
good
news,
so
thanks
must
be
going
great
for
JavaScript,
Python
and
debt
and
go
and
see,
plus,
plus
and
Ruby
and
Swift
and
The,
Collector
and
rest
in
early
in
the
community
demo
in
columns
who's
we're
putting
back
from
the
end
user
working
group.
H
So,
for
example,
we
don't
really
have
collector
specific
questions,
so
that
might
be
something
we
want
to
add
in.
So
if
suggestions
on
like
a
specific
question,
plus
some
responses,
like
example,
responses,
you
would
like
to
be
included,
please
let
us
know
and
I
guess:
I
should
tell
you
where
to
to
do
that:
the
hotel
user
research
Channel
you
can
reach
us
there
or
you
can
ping
myself
or
read
Mancuso
or
Adriana
villela
Darkly
as
well.
C
Awesome
and
is
there
a
plan
for
putting
this
survey
up
somewhere?
Is
there
like
a
campaign
or
anything?
How
does
it
get
released?
Yes,.
H
So
we
would
like
to
get
over
the
next
two
weeks
make
any
updates
motivations
based
on
y'all's
feedback
that
we
can
start
promoting
it,
and
you
know,
have
it
also
ready
by
kubecon
I
mean
I,
know
that's
still
a
while
away,
but
it
would
be
great
to
have
something
ready
and
we
can
be
promoting
before
then.
C
J
Yeah
sure
so
we
got
a
spec
issue
reported
from
a
user
who
surveyed
the
different
sdks
and
found
out
that
that
some,
except
only
200,
as
in
OK
status
code
for
otlp
HTTP
responses,
various
others
do
200
and
202
for
accepted
and
yet
again
others.
They
treat
all
two
XX
error
codes
as
successful,
and
the
spec
itself
is
quite
clear
on
that
and
says
that
any
hotel,
phdp
backend,
should
only
report
200.
J
If
everything
is
successful,
even
if
it's
a
partial
success,
then
it
would
be
a
200
with
a
personal
success
message
to
it,
and
what
what
I
would
like
to
find
out
here
in
this
group
is:
do
you
think
that
the
specs
should
be
more
permissive
there
and
and
and
ask
SDK,
export
or
SDK
and
collect
to
export
those
to
also
treat
the
others
as
successful?
Or
should
we
stay
strict
there?
Because
if,
if
we
want
to
be
more
permissive,
maybe
some
back-ends
don't
have
any
other
choice
other
than
returning
tool
too
I
don't
know.
I
I
So
so,
if
the
exporters
are
running
in
the
browser-
and
it
talks
to
a
back
end
of
the
back-
end
responds
with
a
a
200.
If
the
browser
is
going
through
a
shutdown
mode
that
will
actually
cause
it
to
establish
a
connection
for
every
outgoing
blob
that
it's
got,
which,
if
you're
using
send
Beacon,
could
be
a
lot
and
that
can
actually
cause
the
browser
to
lock
up
and
lose
stuff.
J
I
see
is
that
something
you
could
add
on
the
on
the
issue.
I
think
that
most
are
probably
not
aware
of
the
the
specific
of
of
the
browser
integration
there.
Yeah
I.
I
Onions
only
during
shutdown,
so
it's
what
we
do
internally
in
Microsoft
is
during
that
mode.
We
actually
passed
an
additional
query
string
flag
to
tell
our
back
ends
to
please
return,
a
204
for
everything
successful
rather
than
the
200
and
a
response.
C
Right
so
the
idea
here
is
you're
trying
to
hold
the
browser
Page
open
to
flush,
the
last
bit
of
telemetry,
and
then
you
want
to
shut
down
as
soon
as
you
get
a
response
from
the
server
that
it's
that
it's
received
is
that
the.
I
I
But
if
you
have
a
lot
of
those
backed
up,
the
browser
or
architecture
has
to
establish
multiple
connections
because
we
get
to
200
back
it
loads
up,
and
it
is
nuanced
because
different
versions
of
chromium
do
different
things.
The
modern
one
that
you're
the
latest
one.
That
is
the
case
of
it,
operates
fine
but
yeah,
older
ones.
Don't
you
have
to
actually
reverse
that
round,
so.
C
I
wonder
if
this
is
part,
some
something
we've
seen
just
in
general.
I
wouldn't
block
adding
this
by
the
way,
but
it
seems
like
we
have
a
couple
pieces
of
like
browser,
slash,
client,
specific
infrastructure.
We
need
to
build.
It
seems
clear.
We
need
a
browser,
specific
SDK,
that
shares
a
lot
less
code
and
is
a
little
more
fine-tuned
for
the
browser
and
it.
C
Want
to
just
take
the
collector
stock
collector
and
throw
it
up
publicly
as
a
Gateway
for
clients
to
talk
to
I.
Think
I
think
you
want
to
have
at
minimum
like
The
Collector
configured
into
some
specific
kind
of
like
you
know,
public
Gateway
mode.
Would
you
would
you
agree
with
that?
Like
I'm
wondering
if
there's
like
a
bundle
of
things
that
we
need
to
look
at
as
a
project
in
order
to
to
really
make
it
work
properly,
yeah.
I
So
I
just
pasted
the
link
into
the
sandbox
to
try
and
identify
exactly
that,
so
that
project
is
designed
to
try
and
grab
all
the
JavaScript
stuff
from
J
from
json's
contrib
to
see
if
we
can
make
it
work,
you
know
in
a
web
environment
or
whether
we
need
to
spawn
off
a
completely
separate
version.
I
It's
almost
ready
to
start
for
so
I
am
one
of
the
maintainers
on
that
one.
So.
C
Okay,
yeah
yeah,
that's
a
fork
of
the
the
SDK,
maybe
as
part
of
that
project.
If
you
could
keep
track
of
everything,
you
need
for
a
public
Gateway
to
work
properly
as
well.
That
would
be
like
super
helpful
yep.
I
F
G
Okay,
we're
going
back
to
that
issue
about
whether
all
status
codes
200
through
300,
excluding
excluding
300,
are
treated
as
successful,
so
yeah
I
think
the
spec
is
clear
on
this,
so
only
200
status
code
is
accepted
right
now
we
might
want
to
change
the
spec
to
accommodate
these.
These
other
situations,
but
you
know
the
Java
implementation
currently
accepts
all
all
values
200
to
300
and
I
would
treat
that
as
a
bug
right
now,
unless
the
spec
is
updated.
So.
D
J
J
Yeah
but
I'm
I
could
see
what
what
I
think
Anthony
was
describing
there
as
an
as
an
issue
if
you
terminate
the
old
TLP
connection
like
somewhere
at
an
at
an
outer
layer
and
then
pass
it
on
for
processing.
At
this
point,
you
won't
be
able
to
tell
whether
it's
in
200,
okay
or
whether
it
will
will
throw
up
further
Downstream,
so
I
I
could
imagine.
The
two
two
accepted
would
be
a
reasonable
addition
to
it.
G
D
Yeah
I
didn't
find
anything
immediately
obvious
either.
I
think
for
the
case
that
Nev
brought
up
200
and
204
can
be
roughly
equivalent
was
204
just
saying,
I'm,
not
setting
back
a
body.
It's
okay,
but
I've
still
accepted
this
and
processed
it
I
think
we
could
probably
accept
that
as
long
as
there's
no
partial
success
response
like
partial
success,
would
have
to
give
back
200
with
the
partial
success
data,
but
a
full
success
could
reply
with
204.
C
Also
to
be
like
slightly
pedantic,
this
spec
is
specifying
how
the
server
should
respond,
not
necessarily
the
range
of
status
codes
that
the
clients
should
accept
and
https
and
internet
programming.
It's
common
to
be
like
strict
in
what
you
send
but
permissive
in
what
you
accept
so
and
we're
talking
about
what
range
of
stuff
do.
Do
the
clients
accept
so
I
wonder
if
there's
like.
D
A
difference
there
I
mean
I'm
I'm,
a
fan
of
postal's
law,
but
I.
Think
in
this
case,
where
we're
talking
about
a
specific
application
protocol
and
the
spec
is
clear,
the
200
is
the
only
thing
that
should
come
back
getting
anything
other
than
200
indicates.
You've
got
a
malformed
server
or
a
server,
that's
not
adhering
to
the
spec,
and
that
itself
is
an
error
condition.
B
J
And
it
also
changes
whether
you
lock,
something
or
or
not.
So
if
you
send
or
TLP
to
a
backend
and
it
accepts
it
with
with
tool
two,
then
it's
probably
fine,
but
if
you
have
any
other
I,
don't
know
what
LSD
2xx
range
offers,
but
if
there
is
something
that
would
indicate
an
error
condition,
then
the
SDK
or
collector
exportable,
just
not
lock
the
error,
even
though
you
would
be
interested
in
in
the
the
error
lock
for
that
one.
B
C
C
E
J
You
I
checked
with
tigron
if
he
has
an
idea.
If,
if
that
was
like
a
deliberate
decision
to
do
so,
but
I
think
we
could,
we
could
propose
adding
two
two
and
two
for
to
respect
as
well
cool,
so
I'll
I'll
follow
up
on
it.
Okay,.
C
All
right,
Carlos,
you're
up
next
issue
regarding
the
new
spec
release
in
each
Sig.
A
Yeah,
basically,
as
you
know,
every
time
we
have
a
release
in
theory,
maintainers
can
go
up,
could
go
and
check
what
has
changed
and
create
issues
for
their
own
repos,
but
well
I
got
some
feedback
that
this
is
easy
to
miss,
because
probably
we
don't
have
releases
like
happening
like
for
real
everybody
started
the
start
time
of
the
month
and
other
things,
and
we
have
discussed
also
trying
to
create
automatically
issues
for
things
that
are
new
or
breaking
like
at
this
new
environment
variable
or
at
this
processor,
but
we
never
managed
to
create
something
mostly
because
nobody
had
enough
cycles
for
that.
A
So
I
don't
know
what
to
do.
There.
I
was
thinking
whether
what
maintainers
think
about
just
at
least
having
one
issue
per
each
repo
I
mean
for
British,
see
just
saying
this
new
release
happens.
So
it's
you
know.
This
is
the
change
log
in
the
change
log.
You
know,
which
is
basically
just
all
the
changes
that
happened,
but
this
still
looks
better
than
nothing
and
at
least
that
good
help
you
keep
track
of
whether
you
have
implemented
the
features
of
a
previous
release
or
not
yet.
A
I
was
mentioning
that
automating
at
least
only
let's
say
that
just
creating
one
issue
per
spec
release
right
repo
yeah
going
more,
you
know
like
into
details,
I
think
that
will
that
would
require
more
time.
E
J
Okay,
yeah
I
think
in
the
past
we
we
tried
to
create
some
issues
every
once
in
a
while
when
something
something
merged,
but
I
think
that
just
happened
like
coincidentally.
If
someone
was
really
excited
about
a
feature,
then
they
went
to
all
of
the
the
sdks
and
opened
issues
for
it
to
to
accelerate
that
option.
But
we,
we
didn't
have
any
anything
automated
so
far,
but
I
I
also
agree
that
this
would
make
sense.
C
Okay,
moving
on
next
up,
we
have
Tristan
with
span
processor
decorators,.
K
Yeah
so
I
opened
a
pull
request
to
add
to
the
spec
Matrix.
This
concept
of
span
processor
decorators,
which
are
for
supposed
to
be
for
tagging
and
filtering
and
other
Advanced
scenarios,
is
what
the
spec
says,
which
probably
needs
some
updating,
but
the
so
it'll
be
discussed
more
tomorrow
is
what
I
figured
but
I
wanted
to
ask
in
here,
because
there's
maintainers.
If
anybody
any
language
has
actually
implemented
the
concept
of
span
processor
decorators,
because
that
will
help
me
to
look
through
those
before
tomorrow.
K
I
mean,
though
so
no
because
I
mean
the
on
end
is
an
example.
It's
the
immutable
span,
so
there's
but
The
Decorator.
It
doesn't
specifically
say
this
because
the
spec
is
very
it
just
says
it's
for
advanced
scenarios
for
tagging
and
filtering
and
other
things,
but
I
mean
I,
think
it
implies.
It
can
mutate,
it
I'm,
not
sure
if
it's
supposed
to,
but
so.
L
That
in
Java
to
decorate
the
spans
requires
wrapping
the
exporter.
We
can't
do
that
because
of
the
immutability.
L
G
K
D
You
mean
modify
like
I
view.
Decorator
is
just
wrapping
a
function,
then
another
function
that
makes
some
changes
that
may
be
filtered
without
modifying
that
maybe
modifying
if
it's
happening
in
onstart
or
any
other
sorts
of
things,
but
I
think
all
of
that's
possible
right.
Maybe
the
the
real
question
is
what
sort
of
mutation
and
where
should
mutation
be
happening.
K
Yeah
I
think
well,
and
it
also
I
mean
decorators,
are,
would
be
yeah.
I
mean
the
you
technically
could
for
onstart
do
what
anybody
would
do
for
decorators
with
some
sort
of
composite
type
processor,
but
not
for
on
end
so
yeah.
K
Yeah
I'm,
oh
wait,
I
didn't
link
to
it.
I
just
put
the
quote:
it's
in
like
the
first
or
second
paragraph
under
processors.
I
can
put
a
link
thanks,
but
it
sounds
like
so
Java
has
some
do
you?
What
do
so
I
can
find
them
in
the
code.
You
said
it.
Reps
span,
exporters.
G
We
don't
have
any
explicit
support
for
it.
There's
no
utilities
to
do
this
for
you,
but
if
you
want
to
do
what
you're
suggesting,
which
is,
you
know,
modify
the
span
and
modify
it,
you
know
using
information
that's
available
only
when
Once
the
span
has
ended.
Your
only
option,
for
that
is
to
create
a
custom
span,
exporter,
which
you
know.
E
K
G
F
Go
to
I
think
the
general
thing
that
we're
up
against
here
regarding
processors
is
that
we
have
end
users,
thinking
that
processors
are
the
thing
that
is
going
to
be
able
to
serve
various
use.
Cases
like
on
end
being
able
to
mutate
I
think
that
that's
actually
like
a
pretty
common
expectation
for
end
users,
except
that
the
spec
says
that
shouldn't
be
possible,
though
the
spec
is
also
misleading.
I
think
in
in
this
quote,
that
Tristan
has
has
supplied,
I
I,
think
it
it
kind
of
suggests
it
doesn't
really
state
it
very
clearly.
F
So
at
a
minimum
I
think
you
know
we
need
some
tighter
language,
around
processors
and
then
I
guess
this
is
more
my
opinion,
I
kind
of
want
to
poke
it
eventually,
like
is
this
immutability
constraint
on
end
really
the
right
thing,
but
that's
kind
of
like
a
broader
question.
I
think.
K
I
think
the
yeah.
The
issue
usually
comes
down
to
the
fact
that
each
at
least
each
built-in
span
processor
can
have
an
exporter.
So
mutating
is
problematic
in
that
case,
because
they
could
each
be
exporting
the
same
data,
so
you'd
have
to
Define
that
you
have
to
copy,
and
people
won't
like
that
and
then
so
just
having
it
be,
you
can
copy
and
do
modifications
in
that
The
Decorator
would
provide
that
functionality.
K
C
It
almost
sounds
like
in
like
an
exporter
decorator
than
a
Spam
processor
decorator,
from
the
brief
description,
Jack
gave
right,
you're
saying
you
you're,
intercepting
it
on
the
way
to
the
export
or
not
during
the
spam
processor
stage.
K
G
No
you're
right,
Tristan,
the
contacts
is
lost
at
that
point.
Okay,
because
you
know
you
you,
you
add
the
spans
to
a
queue
and
then
export
them
asynchronously.
So
I.
K
D
One
common
request
we
hear
is
the
ability
to
have
like
Trace
level
attributes
or
to
mimic
them
by
saying
every
span
that
comes
through
with
this
Trace
ID.
Add
these
attributes
to
them
at
export,
and
you
can't
really
do
that
easily
right
now,.
C
It
seems
like
both
of
these
are
are
things
we
want
to
tackle?
I
totally
agree
that
we
need
some
concept
of
like
a
trace
level
attribute
to
avoid
co-opting
baggage
to
to
do
this,
like
it
works,
but
it's
it's
a
it's
an
expensive
hack
to
have
to
send
that
data
all
the
way
down
the
line,
if
the
only
point
of
doing
so
is
to
to
create
a
quote.
Trace
level
attribute.
C
Also
you
all
the
spans
that
came
before
you.
You
attach
that
piece
of
baggage
aren't
going
to
have
the
attribute
type,
so
it's
kind
of
a
whole
and
I
definitely
know
of
some
tracing
systems
that
have
this
concept
and
I
also
agree
with
the
point
that
Alan
brought
up,
which
is
this
there's.
C
Reason
for
why
we
have
immutability,
where
we
do
so.
It's
not
like
a
simple
fix,
but
I
also
feel
like
plenty
of
people
run
up,
want
to
do
a
simple
thing
of
modifying
the
span
after
it
ends.
It
seems
like,
like
kind
of
a
core
use
case,
to
be
able
to
do
that,
while
still
having
the
context
available
and
not
having
a
place
in
our
SDK
pipeline,
where
you
can
do
that
sanely
and
safely
without
creating
a
lot
of
extra
data
seems
seems
like
a
hole.
C
I,
don't
know
how
like
straightforward
it
would
be
to
to
plug
it,
but
I
actually
agree
that.
That's
that's
that's
an
improvement
we
could
make.
That
would
make
life
a
lot
simpler
for
a
lot
of
things.
End
users
want
to
do
including
this
off
by
one
error.
You
would
expect,
when
you're
attaching
baggage
to
a
span
that,
if
you
attach
the
baggage,
if
you
created
baggage,
that
the
currently
active
span
would
get
that
baggage,
not
the
back.
Just
the
baggage
before
seems
to
me.
C
That's
like
a
kind
of
subtle
off
by
one
expectation,
error.
C
I
bet
end
users
get
tripped
up
by
that.
We've.
L
Had
many
several
end,
users
tripped
up
by
baggage
being
immutable.
E
L
C
Yeah
yeah
I
mean
it.
It
makes
sense
for
baggage
to
not
be
I,
don't
think
baggage
can
be
mutable
safely,
but
you
would
want
to
be
able
to
hook
into
the
creation
of
a
new
piece
of
baggage
being
able
to
do
something
to
the
span.
I
mean.
Maybe
it's
doesn't
have
to
be
a
span
processor.
Maybe
it's
more
of
a
the
baggage
processor
that
grabs
the
current
span
and
just
attaches
an
attribute
like
normal
or
something,
but
it
it
if
it's
not
feasible
to
do
something
like
that
in
a
straightforward
manner.
C
C
We
need
to
to
spend
some
Cycles
on
at
some
point
around
just
sort
of
reviewing
our
SDK
pipeline
in
relation
to
some
like
common
common
complaints
and
confusions
from
end
users,
I
would
I
would
want
to
maybe
I,
don't
know
when
we'll
have
the
Cycles
to
do
this,
but
I
would
be
down
to
to
help
with
an
effort
to
just
go
to
go
to
all
the
different
language
cigs
and
just
collect
up
this
kind
of
feedback
and,
like
put
it
somewhere,
you
know
like
actually
process
it
as
a
project
rather
than
doing
a
bunch
of
one-offs,
I,
don't
know
anyone
else
feels
like
that
would
be
a
useful
effort.
C
Because
I
suspect
there's
actually
like
a
small
pile
of
things
that
maintainers
are
seeing
through.
Like
common.
You
know,
Common
pieces
of
feedback
from
end
users,
but
they
can't
change
or
address
the
the
feedback
they're
getting
for
the
end
users,
because
it
would
involve
changing
the
spec
and
they
don't
got
time
for
that.
So
maybe
that's
a
worthwhile
effort
to
just
have
a
an
SDK
feedback
review
project.
F
So
yeah
I
think
that's
an
interesting
idea.
I'd
be
interested
in
talking
more
about
that
talking,
specifically
about.net,
because
that's
where
I
come
from,
you
know
we
don't
actually
have
the
immutability
constraint
in
the
same
way
as
some
of
the
other
languages
do
in
our
processors.
F
Also,
in
speaking
with
Tristan
about
this
last
week
and
Daniel
in
the
scope
of
JavaScript,
it
seems
like
JavaScript
is,
has
technically
implemented
immutability,
but
because
of
the
nature
of
the
language
you
know
it
makes
it
actually
pretty
difficult
to
conform
to
the
spec
in
that
way.
So
you
know
these.
These
differences
across
our
languages
is
yet
another
element
that
kind
of
confuses
end
users.
Well,
specifically
like
end
users
of
polyglot
shops
that
you.
E
F
Have
are
trying
to
do
same
similar
things
across
languages.
C
Cool
okay,
well,
I,
don't
I,
don't
have
time
to
to
add
another
project.
This
cycle
and
I
think
we're
we're
maxed
out
on
projects
right
now.
But
if
anyone
wants
to
start
collecting
that
feedback,
you
know
I
would
say,
go
to
it,
go
for
it
and
reach
out
to
me,
and
let
me
know
if
you're
you're
doing
it,
but
it's
definitely
I
think
it's
something!
That's
not
going
to
go
away.
So
we
should
tackle
this
at
some
point.
C
And
yeah
I
see
Matt.
We
are
saying
in
the
comments
the
chat
that
sacrificing
parallel
pipelines
in
favor
of
mutability
would
be
like
one
potential
trade-off
that
might
be
worthwhile
I
kind
of
agree
that
we
made
some
assumptions
about
like
where
what
our
end
users
priorities
are.
As
far
as
like
SDK
architecture,.
I
K
D
D
B
E
B
The
problem
problem
there,
though,
is
then
like
how
does
that
work
in
the
full
processing
pipeline
right
because,
like
does
that,
go
down
the
span
processors
pipeline,
that
it
holds
itself,
but
does
it
go
down
all
the
other
processors
below
it
because
I
think
that's
where
a
lot.
D
Of
well,
if
it's
wrapped,
yes,
like
if
you're
calling
another
processor,
then
that
you
you
you're
in
control
of
what
you
hand
to
that
processor,
but
for
any
other
processors
that
the
SDK
is
managing
it's
going
to
give
them
the
same
immutable
data
and
they
can
choose
to
make
a
mutable
copy
of
that
for
themselves
or
not
yeah.
Okay,
that's
that's!
Basically,
the
design
The
Collector
is
moving
towards.
C
Yeah
I,
don't
I,
don't
I
think
it's.
This
is
like
complicated
enough
knot.
I
don't
think
we
can.
We
can
just
casually
untangle
it,
which
is
why
I
feel
like
it'd,
probably
be
good
to
to
get
a
bundle
of
feedback
before
tackling
it,
because
my
my
senses
there's
probably
a
way
to
shim
in
an
additional
concept.
Like
you
know,
person
saying:
hey:
we've,
maybe
through
the
back
door,
we
can
do
it
with
this
vaguely
defined.
You
know,
span
decorator
concept,
but
that
my
instinct
would
be
yeah.
C
C
The
design
of
it
is
such
that
you
aren't
worried
about
there
being
multiple
copies
floating
out
there,
interacting
with
the
same
data
in
a
non-thread
safe
way,
and
you
know,
then
you
would
use
that
as
like
the
safe
place
to
put
this
kind
of
mutation
but
I,
don't
we're
not
going
to
solve
it
in
the
next
three
minutes.
I
do
think
it's
a
worthy
thing
to
solve,
though,
because
it's
this
seems
like
a
piece
of
feedback
that
we
get
consistently
and
I
would.
C
K
F
C
Well,
let's,
let's
move
on
Anthony
you've
got
some
otlp
guarantees
I'd
like
to
discuss.
D
Yeah,
so
this
is
a
draft
PR
that
tigrid
has
had
up
for
a
while
and
now
that
otlp
Json
is
marked
as
stable
in
the
spec
and
Proto.
We've
already
got
some
questions
about
why
we
don't
have
otlp
1.0
I
think
this
is
the
last
thing
holding
us
up
is
actually
agreeing
on
what
sort
of
guarantees
we
mean
by
giving
it
a
1.0
tag.
You
know
what
what
is
the
the
extent
of
the
surface
area
of
the
API
effectively
is
the
question
here:
I
am
in
support
of
The
Proposal.
D
That
tigrants
made
I
think
there's
General
consensus
on
this
on
various
other
discussions,
but
we
now
need
to
get
this
moving
forward.
So
if
people
could
review
that,
PR
leads
comments
on
things
they
like
don't
like
and
help
us
get.
This
moving
forward.
I
think
that'll
be
great.
C
F
C
This
relates
by
the
way,
just
as
an
aside
once
we
get
the
rest
of
our
kind
of
spec
project
management,
stuff
stood
up,
I
think
we'll
have
enough
infrastructure
at
that
point
to
add
some
concept
of
like
official
public
review
periods
for
the
important
things
you
know
just
just
a
better
way
of
being
able
to
say,
like
we're,
gonna
merge
this
thing
so
last
call
and
being
able
to
maybe
tell
people
ahead
of
time
that
they
should
come
look
at
something
important
so
that
we're
not
waiting
months
and
months
to
merge
something
just
to
make
sure
everyone
gets
to
say
in
if
we
can
get
a
little
more
organized
about
that,
we
can
start
have
a
wave
like
automatically
putting
those
things
up
on
the
website
or
something
else
just
to
to
make
that
process
a
little
bit
smoother
for
people.
C
So
that's
something
I'm
trying
to
work
on
right
now:
cool,
okay,
that's
certainly
not
least
Trask
HTTP
Hispanic
conventions.
L
A
little
bit
of
a
tie-in
to
what
you
were
just
talking
about
in
that
we
are
the
symmetic
HTTP
semantic
convention
stability
group
has
been
is
following
Ted's
proposal
here
on
semantic
convention
process
and
timeline
as
we're
sort
of
Guinea
pigging
the
process,
but
I
wanted
to
call
out
for
this
group
in
particular
that
in
the
the
dates
in
the
meeting
notes,
but
it
is
a
fairly
aggressive
timeline
because
we
have
a
lot
of
semantic
conventions
that
we
want
to
stabilize
and
and
HTTP
is
long
overdue.
L
But
that
does
mean
that
if
there's
anything
that
anyone
here
thinks
that
we
should
be
looking
at,
please
bring
that
to.
You
know
open
a
file,
an
issue
or,
if
there's
already
an
issue
which
is
not
tagged.
L
L
Also,
for
example,
you
know,
if
there's,
if
we're
going
to
change
the
the
unit
name,
that
would
we
have
to
do
that
before
we
Mark
HTTP
semantic
convention
stable
and
then
the
last
thing
to
call
out
kind
of
for
this
group
is
there's
kind
of
the
one
big
thing
in
the
air
right
now
that
we
don't
know
which,
where
it's,
how
it's
going
to
go
yet
is
the
ECS
alignment
with
elastic
common
schema.
L
L
But
our
the
working
groups,
the
HTTP
semantic
commission
stability
working
groups,
opinion-
is
that
this?
If
we're
going
to
do
this,
then
we
need
to
do
this.
For
HTTP
we
need
to
align
before
HTTP
goes
stable.
If
we
don't
align,
if
we
don't
align
HTTP,
then
we
should
just
close
this
Otep
or
you
know
the
there
can
be
things
I
think
Riley
mentioned
like
oh
somewhere
else.
You
know
we
could
work
on
mappings
from
ECS
to
open
Telemetry
schemas,
but
we
would
not.
L
We
wouldn't
try
to
align
anymore.
So
we
are
I'll
I'll,
be
presenting
more
about
this
in
tomorrow's
spec
meeting.
L
We
do
want
to
and
Riley's
been
pushing
on
the
ECS
side
to
understand
their
kind
of
commitment
level.
If
we
do
pursue
this,
obviously
it
would
be.
You
know
breaking
and
we
are.
We
have
a
lot
of
solutions
out.
There
built
people
have
itself
built
on
this
existing
conventions
so
nobody's
taking
breaking
lightly,
even
though
you
know
it
hasn't
been
marked
stable
yeah.
So
that's
it
just
wanted
to
draw
attention
to
those
things.
L
C
Yeah
I'm
interested
to
see
where
this
goes
with
the
ECS
when
they
had
came
to
when
they
came.
C
The
proposal
of
merging
the
two
things
they
as
part
of
that
put
forward
that
for
any
disreparency
between
the
two
standards
they
would
the
existing
open,
Telemetry
attributes
could
stay
the
same
and
they
would
handle
it
on
their
end
to
to
figure
out
a
mapping,
but
I
feel
like
that
was
like
an
earlier
regime
of
ECS.
People
like
I
think,
like
the
actual
humans
involved,
have
kind
of
swapped
out
since
then,
but
just
putting
it
forward.
That
was,
that
was
what
they
originally
claimed.
They
were
gonna
do
to
to
solve
this.
L
C
C
I
C
L
L
Ecs
is
necessarily
saying
you
know,
hey
you
have
you
should
do
this.
You
have
to
do
this
I
think
as
the
working
group
like
Riley
Josh
and
myself
have
looked
at
the
ECS
schema
more
and
more
and
their
GitHub
repo
and
like
it.
This
is
a
schema.
That's
been
around,
for
you
know,
10
years.
F
L
Is
impressive
and
stable
and
you
know
there's
some
good
things.
We've
learned
some
good
things
about
it
like
if,
if
I
had
the
chance
to
do
it
over
like
in
our
schema
right,
like
I,
think
I
would
change
HTTP
URL
to
URL
dot
stuff
so
that
we
can
share
that
URL
namespace
across
different
semantic
conventions,
and
that's
something
that
they've
done
I
also
kind
of
like
the
the
net
stuff
is
very
tricky.
L
We
we
had
a
couple
of
meetings
with
Alex
from
ECS
last
week
with
lidmilla
and
myself
to
like
try
to
understand
the
net
mappings
at
the
core
that
we
would
need
to
introduce
some
new
stuff
over
there.
They
don't
model
like
this
low-level,
socket
stuff
versus
high
level,
the
one
difference
they
do
have,
which
I
think
is
kind
of
nice,
but
I
guess
it's
certainly
debatable.
Is
they
label
instead
of
doing
peer
and
host
meaning
host
is
myself
here
is
my
remote?
L
They
always
label
things
client
and
server
so
that
the
Telemetry
sort
of
matches
up
from
both
sides,
but
that's
less
useful
than
yeah
the
main.
L
The
big
one
was
this
idea
of
sharing
same
with
the
user
agent
I
think
we
probably
will
go
ahead
with
this
change,
because
it's
less
it's
a
less
critical
attribute
for
one
thing
than
like
HTTP,
URL
and
also
user
agent
in
general,
as
nip
pointed
out
here,
is
basically
going
away
and
so
they'll
be
like
multiple
sub
things
that
you
can
capture
of
the
user
agent.
So
it
seems
to
make
a
lot
of
sense
for
it
to
become
a
a
group.
C
Awesome
cool
well,
I'm
glad
you
guys
are
talking
with
them
to
the
hashtag,
because
it
personally
I
think
it
would
be
great
if
the
two
standards
could
actually
merge
rather
than
having
two
groups
working
in
parallel
on
the
same
stuff
and
trying
to
somehow
stay
kind
of
synchronized
with
each
other.
It
seems
better
if
we
could
rip
the
Band-Aid
off
and
you
know
have
one
group
working
together
on
this
stuff,
but
I,
don't
know
how
realistic
that
is.
L
Yeah,
my
one
thought
from
you
know
the
breaking
is
you
know
the
justifying
breaking
is.
If
we
could,
you
know
have
this,
you
know
because
it
would
be
a
fairly
big
announcement,
like
of.
I
L
C
Yes,
yeah,
no
I
I
completely
agree
there.
It's
actually
the
only
reason
I
can
think
of
that
would
ever
justify
it,
which
is
that
we're,
oh
I
forget
the
number
I
should
have
the
number
that
XKCD
comic
memorized
at
this
point,
but
every
time
we're
we're
doing
the
opposite
of
we're,
taking
away
a
standard
instead
of
creating
one
I.
Think
that's
like
a
worthwhile
effort,
so
anyways
I'm
glad
you
guys
are
are
tackling
that.
It.
C
Okay,
so
we've
got
four
minutes
left
just
to
to
finish
this
out
really
quick.
We
only
have
two
oteps
left
that
we
have
not
triaged.
C
So
let's
just
have
a
look
at
these
two
really
quick.
The
first
one
is
no
tap
on
sensitive
data
handling,
which
is
like
this
person
has
kind
of
an
approach,
they're
proposing
to
scrubbing
data.
C
I'm
wondering
does
anyone.
That's
called
know
whether
this
this
has
basically
been
superseded,
since
this
is
a
couple
of
years
old,
are
there
newer
initiatives
around
scrubbing,
SQL
and
other
things
that
we
could
close
this
PR
in
favor
of.
L
C
J
Like
the
like,
the
current
spec
PR
is
because
that
one
also
says
you
should
in
capital
letters
you
should
scrub
sensitive
data
and
as
an
SDK,
if
you,
if
you
don't,
have
any
means
of
doing
so,
then
then
you
must
present
good
reasoning
for
by
your
breaking
this
requirement.
J
J
A
Sounds
like
it
would
require
a
working
group
honestly,
it's
like
a
big
effort,
a
lot
of
stuff
to
Define
yeah
and
it's
it's
great,
a
big
project
and
yeah
not
for
now
yeah.
J
C
J
C
Extending
our
our
yaml
definition
of
them
to
include
a
like
is
is
sensitive
field
or
something
like
that,
like
a
Boolean
for
each
attribute
indicating
whether
that
attribute,
if
you're
going
to
have
like
a
default
set
of
scrubbers.
This
is
like
an
attribute
that
should
be
scrubbed,
because
we
know
for
a
fact
there
may
be
sensitive
data
in
this
attribute.
C
C
But
anyways
I'll
I'll
just
label
it
triage
for
now
and
and
I
won't
close
it
because
it
still
seems
relevant,
okay,
last
but
not
least,
a
proposal
to
expand
and
improve
span
events.
So
this
is
from
a
long
time
ago
about
coming
up
with
more
detailed
Nuance
around
different
types
of
span.
Events
I
think
this
it's
safe
to
say
this
is
superseded
by
the
log
events
proposal
that
has
already
gone
through.
L
C
Cool
anyways
I'm
going
to
go
ahead
and
close
this.
If,
unless
anybody
has
objections
which
I
doubt.