►
From YouTube: 2023-02-01 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
Hey
folks
can
can
someone
please
run
the
meeting.
I've
got
a
bit
of
a
sore
throat,
don't
mind.
B
I
I
pulled
up
the
notes
here,
so
it
looks
like
a
tigrant.
You
know
if
you're
wondering
you
know
what
else
we
need
to
do
before.
We
can
declare
the
logspec
stable.
A
Yeah,
so
there's
that
issue
I
was
wondering
if
anybody
has
any
thoughts
on
what
else
we
need
to
do.
A
That's
basically
the
question
I
have
and
if
not,
then
there's
really
the
dotnet
checkbox
is
remaining
I,
don't
know
if
we
have
anyone
from
Top
net
here.
C
You
have
those
we
built
our
prototype
based
on
the
event
API,
so
I
don't
know
if
that
has
changed,
but
we
don't
really
use
the
event
API
for
Siri
log
we're
just
using
log
API.
A
A
And
so
yes,
please
double
check
if,
if
it
is
then
boom
Market
complete
and
then,
if
there's
nothing
else
that
we
think
is
necessary,
then
we're
ready
to
present,
essentially
what
we
have
to
the
to
the
maintainers
and
specifications
seek.
Oh
fantastic:
okay
thanks
everyone,
and
if
you
have
any
other
thoughts,
if
you
think
something
is
missing
before
we
can
declare
them
stable.
B
Awesome
that'll
be
great
to
have
that
flag.
Finally
flipped,
so
the
next
one,
then,
is
about
encapsulating
event
payload.
In
the
event,
data
attribute
just
pulled
up
this
PR.
B
B
Nafta
I
think
that's
yours.
Do
you
want
to
talk
about
it.
D
Yeah
this
has
been
going
around
for
a
while.
Santosh
is
also
contributing
to
this,
so
he
did
the
last
push
and
there's
a
a
typo
that
is
going
to
fix
later
today.
But
this
is
really
about.
You
know
defining
what
foreign
name
event
domain:
where
does
the
data
go?
So
this
is
really
saying
we
have
event,
name
event,
domain
and
event.
D
D
Which
I
do
talk
about?
In
the
last
paragraph
of
the
description
of
the
pr
yeah?
This
does
not
preclude
adding
additional
attributes
and
we,
you
know,
we
suspect
there
will
be
people
who
want
to
add
additional
attributes
and
there
may
be
other
attributes
we
have
to
add.
D
But
this
is
just
saying
for
our
defined
domain.
You
know
so
the
domain
name
identifies
the
event.
So
for
that
event,
we
will
go
up
and
Define
that
everything
in
event
data
is
what
is
expected
as
as
defined
for
that
event,
the
domain
name
combination.
B
D
Yeah,
so
we
want
some
level
of
compatibility
and
say
we
have
an
event
whether
the
event
is
going
by
our
logs,
which
is
our
only
way
to
send
it
now,
because
it's
a
nested
attributes.
So
that's
the
only
thing
that
supports
necessary
support
or
eventually,
whether
we
or
someone
wants
descended
via
a
span
event.
D
B
I
can
see,
that's
appealing,
you
know
I
take
around
like.
Are
there
sort
of
other
cases
where
we've
already
sort
of
made
a
call
on
something
along
those
lines
where
you
know
the
the
fact
that
it
could
also
be
then
then
embedded
in
a
span?
You
know
with
Trump.
You
know
what
would
otherwise
probably
lead
us
to
suggest
that
we're
putting
it
in
a
body.
B
B
Opinion
is
that
we
don't
your
your
argument
for
making
it
so
that
you
can
also
put
it
in
a
span.
Is,
is
actually
pretty
good
and
don't
really
have
as
good
of
an
argument
for
putting
it
in
the
body
other
than
like.
That's
technically,
where
it's
I
guess
supposed
to
go,
but
I
think
that's
all
I
can
say
myself.
D
Yeah
I
think
we've
gone
around
in
in
circles
for
like
a
few
months
ago,
we
had
a
big
discussion
about
this
as
well.
So
I,
don't
remember
when
that
was
I.
Think
tigran
made
notes.
No
in
the
our
meeting
said
notes
there
somewhere.
D
Where
we
talked
about
the
event
data
versus
body,
so
we
talked
about
this
again
ages
ago,
so.
B
D
A
Which
which
technically
doesn't
prevent
binary
data
correct
or
one
of
the
attributes
there
right?
That's
still,
okay,
you
can
do
that.
D
You
know
there
would
be
a
slight
advantage
of
dropping
it
into
body
and
that
instead
of
saying
data
is
only
Nest
attributes.
We
could
then
say
it's
just
a
Json
blob
or
it's
just
you
know
a
more
concise
form
of
sending
the
data.
It's
just
in
terms
of
what
exists
today
at
the
API.
You
know
an
attribute
definition
is
the
closest
thing
or
it
would,
and
in
some
cases
we
will
have
events
that
will
leverage
the
existing
semantic
conventions
to
have
similar
names
for
their
values.
B
Okay,
so
from
your
perspective,
you
know
if
you
could
do
it
as
proposed
with
event
data.
That
would
be
more
Universal
for
your
use
case
and
more
pragmatic
and
probably
would
lead
to
more
adoption,
because,
like
more
Universal
being
that
you
can
use
it
in
either
context
whether
folks
are
using
logs
or
spans.
D
Yeah
and
it's
also
back
Ends-
don't
have
to
do
anything
special,
so
in
fact,
we
just
have
end
up
being
a
bunch
of
attributes
that
they
can
then
go
and
store
wherever
they
need
to
regardless
of
yeah.
They
don't
have
don't
have
to
have
special
logic.
To
say,
I
know
that
this
domain
does
this,
they
can
say.
B
And
you
would
think
of
that,
that
being
potentially
backends
that
are
specialized
to
do
only
this,
you
know,
rather
than
you
know,
the
sort
of
breed
of
back
ends
that
can
do
everything.
D
No
I
I
think
it
appears
to
you
that
you
know
back
ends
that
do
everything,
and
this
just
says
whether
it's
our
defined
hotel
events,
application
and
custom
events.
They
don't
need
to
know
about
it.
They
just
pick
it
up
and
deal
with
them
in
the
same
manner
yeah
so
that
you
know
they
can
say
the
event
data
is
available
here
they
could
potentially
provide
indexes
to
to
make
it
a
little
bit
smoother
for
applications.
D
B
B
D
Yeah
so
so
we
flipped
it
from
draft
to
active
this
morning.
So
yeah
we're
just
looking
for
feedback
approvals
and
how
could
they
do
that
merge.
E
D
No,
this
is
for
logs.
So
by
saying
event,
you
know
right
now
we're
we're
defining
this
as
we're
doing
this
on
top
of
logs
I
think
we
can
push
this
in
even
before
tigrants.
The
general
nested
attribute
support
across
everything
yeah.
D
E
B
B
Doesn't
appear
to
be
the
case?
Okay,
so
you
know
following
order,
I
don't
know
secret.
What
do
we
do?
Do
we?
Just
basically
you
know,
approve
it
from
the
for.
Is
this
a
log
specs
approver
item.
B
B
Cool
I
I
know
what
I
will
do,
but
all
right
thanks,
nav.
B
And
then
there's
one
more
another
pull
request
on
log
record
ad.
Let
me
pull
it
up
real,
quick
anybody
on
the
call
Santosh
Maybe.
F
G
Sorry
I
have
to
I
have
to
unmute
myself.
Just
give
me
a
second
there.
It
is
yeah,
so
I
I
raised
this
already
a
while
back
and
then
wanted
just
to
to
get
back
to
this
conversation.
Once
again,
this
is
around
having
a
unique
ID
to
to
identify
a
lock
line
and
Santosh
added
the
same
sort
for
event.
G
The
use
cases
are
the
one
is
of
course
deduplication,
but
but
the
one
that
we
have
more
in
mind
is
like
to
to
link
locks
across
tools
right
if
I
have
a
lock
line
into
one
tool,
I
want
to
identify
it
in
the
other
tool
and,
as
it
looks
right
now,
this
this
is
of
course,
not
possible
without
having
an
ID
like
we
have
it
with
traces
or
other
other
things,
and
then
this
is
the
proposal,
and
but
but
there's
still
a
few
open
questions
on
that
right.
G
I
mean
there's
the
one
question
like
okay:
if
we
introduce
such
an
attribute
in
the
semantic
conventions
who
who
is
going
to
to
generate
this
attribute,
so
is
it
the
lockup
hander?
Is
it
the
SDK?
Is
it
the
end
user
who's
taking
care
of
that,
and
then
the
other
question
I
think
this
came
from
Santosh
is
around?
G
E
No,
the
second
one
I
realized
later
after
adding
the
comment
that
now
that
we
have
a
separate
events,
SDK
and
an
events
API
separate
from
the
log
API
and
SDK.
It
is
okay
for
the
semantic
convention
for
the
event
ID
to
be
different.
Okay,
so
I'm,
okay,
dropping
that
question
here.
G
Okay,
so
then,
then
it's
more
around
the
the
first
question
like
okay.
If,
if
this
attribute
is
introduced,
how
is
it
going
to
to
be
emitted
right.
D
Yeah,
so
probably
just
as
a
ref
one
of
our
internal
sdks
that
I
work
on
effectively
this
is
both
user
supplied
and
that
the
user
doesn't
Supply
the
SDK
populated
I'm
gonna
go
in.
So
it's
probably,
it
feels
like
it's
probably
a
similar
situation
where,
if
someone
wants
to
link
them,
they
can
provide
the
ID,
but
failing
that,
if
you
happen
to
have
it
turned
on
because
again
we
have
a
behind
a
conflict
flag.
There's,
not
everyone
wanted.
B
G
A
Think,
yes,
because
it's
I
don't
know
how
often
people
will
want
to
see
this
right
like
does
everybody
want
it
or
or
the
opposite
of
the
small
population
of
folks
want
to
to
have
that
right?
We
don't
want
to
it's,
not
a
small
attribute
as
well
right,
so
I
don't
know
if
we
want
to
have
it
by
default.
On
always.
H
E
Regarding
the
small
versus
large
attribute
does
it
have
to
be
a
uuid
because
it
has
to
be
unique
from
that
source?
So
so,
as
long
as
this
resource
plus
ID
is
unique,
it
should
be
okay,.
G
But
I
agree
this.
This
might
not
be
necessary
right.
You
could
use
something
shorter
than
that,
but
but
I
have
no,
no,
no
good
experience
or
no
strong
preference
on
that.
E
Regarding
whether
we
want
to
do
it
by
default,
I
think
Severance
original
requirement
was
that
from
the
clients
from
The
Source
itself,
if
we
end
up
sending
the
same
log
records
to
two
different
destinations
and
then,
if
we
want
to
compare
them,
it
would
be
easier
if
an
ID
was
added
at
the
source.
B
Yeah,
so
my
take
is
in
in
the
system
that
I
know
best
Aid
is
I
generated
and
assigned
you
know
by
the
back
end,
but
that
doesn't
have
to
be
like
that
everywhere.
I
also
feel
that
it's
like
I'm
with
tigrant
I
think
this
should
probably
be
optional
that
because
it
feels
like
this
is
potentially
highly
back
in
specific
I
mean
back
against
it
might
care
about
it.
You
know
reasonably,
so
you
know
like
the
ones
that
you
guys
were
present
and
others
might
might
just
not
really.
F
G
Let's
say
you
create
metrics
across
logs
and
then
you
want
to
sell
like
a
and
by
the
way,
some
kind
of
Exemplar
I'm,
not
sure
if
this,
if
this
works,
but
if
you
say
like
hey,
I,
create
metrics
and
logs
and
by
the
way
this
this
one
lock
line
here
is,
is
an
example
for
for
what's
going
on
here,
you
suddenly
need
this
ID
as
well
or
if
someone
says
like
hey,
give
me
I
want
to
attach
this
log
line
to
and
ticket
or
send
it
out
to
someone
or
I
said,
have
it
in
in
two
different
tools
and
want
to
jump
from
from
one
I.
G
Don't
know
from
my
application
monitoring
into
my
security
monitoring,
and
then
this
lock
line
is,
is
the
one
thing
I
I
want
to
link
there?
Then
then,
this
idea
becomes
this.
This
ID
becomes
extremely
valuable,
but
yeah
I
said
I
mean
the
problem.
Is
those
things
are
not
billed
yet?
But
as
long
as
you
don't
have
this
ID,
you
cannot
so
it's
a
little
bit
of
a
chicken
ACT
problem.
So.
A
So,
with
Trace
ideas
and
span
ID
you're
right,
they
are
used
for
stitching
stuff
together
right.
We
we
don't
only
that
they
are
fundamental
part
of
the
data
model.
We
don't
only
say
how
and
where
to
store
them
and
generate
them,
but
we
also
Define
places
where
you
can
reference
other
IDs
right,
like
a
parent
span
or
the
trace
ID
stitches
spans
together.
A
A
I,
don't
know
how.
If
we
want
to
reference
a
log
record
from
elsewhere,
then
we
need
to
say
how
we
do
that
right.
Is
it
from
another
attribute?
What
is
that
attribute?
Does
it
have
a
specific
name?
Is
it
from
a
Spam
as
well
from
I,
don't
know
somehow
from
a
metric
and
as
an
exampler
or
something
like
that
right
unless
we
Define
more
specifically.
A
B
B
What's
being
so
like
mapping
that
back
to
stuff
that
I've
seen
is
you
know,
there's
like
from
the
sort
of
sumo
experience
there
are
places
where
customers
have
asked
us
to
forward
the
data
to
a
separate
system,
usually
something
like
S3
or
so
so
that
they
can
have
a
backup
of
the
data
and
maybe
have
their
own
retention
policies
and
whatnot
and
and
then
you
know
the
data
would
it
would
basically
be
the
same
thing,
but
in
two
places
and
like
at
least
in
the
current
Zoom
architecture,
that's
just
a
system
that
I
happen
to
know
the
event
is
the
adid
is
assigned
by
the
backend,
so
the
stuff
just
goes
without
IDs
more
in
a
more
fashioned
right
into
the
backend
So
Into
The
Entity,
into
whatever
other
place
or
the
other
destination.
B
They
want
to
put
it.
So
you
know
I
I,
hear
sirens.
You
know
you
know
points
on
why
it
would
be
useful
and
I
I'm
not
going
to
argue
that
I
think
it
would
be
very
useful,
I'm
just
wondering
whether
we
can,
whether
we
can
whether
it
makes
sense
to
to
force
it
I
think
it
probably
doesn't
for
what
it's
worth.
B
You
know
we
would
then
also
it's
about
sdks.
That
would
have
to
basically
you
know,
add
it
or
pass
it
through.
We
would,
if
we,
if
it
was
there,
we
would
already
then
also
have
to
look
at
the
receivers
that
take
logs
and
allow
people,
maybe
as
a
processor,
so
you
know
to
add
an
ID
if
desired.
I
could
see
that
you
know
being
useful
like
in
theory.
B
Writing
such
a
processor
is
probably
you
know
that
doesn't
sound
terribly
hard
I'm,
just
struggling
with
making
it
mandatory,
and
then
that
that
that's
my
take,
and
the
second
thing
I'll
say,
is
that
I
think
I
think
the
the
UL
ID
stuff
is
becoming
quite
popular
and
it
seems
like
a
reasonable
thing
to
put
there.
B
If
you
have
that
field
again,
I'm
also
wondering
whether
you
want
to
make
a
particular
format
mandatory,
because
you're
pretty
much
looking
for
something
opaque.
That's
hopefully
unique
right
and
you
know
folks
might
have
different
opinions.
I
still
want
a
good
source
of
uniquenesses,
etc,
etc.
Right
and
like
as
long
as
it's
Unique
for
whoever
is
using
it
in
their
context,
then
we
might
not
have
to
make
it
mandatory.
D
Yeah
and
I
guess
in
my
con,
in
my
scenario,
I'm
most
of
my
sdks
get
used
on
the
front
end
on
a
client,
not
not
a
back
end,
so
it
really
is
the
front
end
defines
its
ID.
We
pass
it
through
as
a
string,
but
if
it's
not,
if
they
don't
provide
it,
we
happen
to
generate
a
w3c
good
to
populate
it.
If
they
ask
us
to
I,
also
have
another
SDK,
that's
built
on
top
of
this
well,
in
fact,
they're
built
in
parallel
that
share
the
same
code.
D
You
know
one
version,
never
populates
it.
The
other
version
has
the
option
to
populate
it,
so
so
yeah
I
think
it
needs
to
be
optional,
at
least
from
the
SDK
perspective.
G
My
point
of
view
I
mean
yeah
I
mean
just
just
thinking,
thinking
to
it
through
the
use
cases
that
I
see
and
even
if
you
see
like
no
sdks
implementing
it
and
having
it
done
by
some
kind
of
processor
on
The
Collector
or
something
like
that
before,
for
example,
sending
it
out
to
to
multiple
backends
I
I
would
I
think
I
agree
that
this
is
probably
good
enough
right
to
to
only
have
it
if
you
need
it
yeah,
so
so,
I
I
always
think
I
would
be
okay
to
to
have
it
optional,
but
but
nevertheless,
my
understanding
is
that
if,
if
it's
going
to
be
populated,
the
either
and
and
processor
or
the
SDK
itself
doing,
it
seems
to
be
a
reasonable
option
right.
G
A
G
I,
don't
remember
correctly,
but
but
you
could
do
something
like
that
right,
you
could
say
like
hey
and
add
me
in
an
ID
if
there's
none
and
then
otherwise,
they
just
take
what
you
have
yeah
okay,
so
so
then
I
I
will
see
that
did
I
make
it
optional.
G
Should
there
also
be
a
suggestion
in
in
the
semantic
conventions
PR
that
says
like
hey,
this
should
be
done
by
the
SDK,
or
this
should
be
done
by
the
by
a
processor
or
should
should
this
be
left
out.
There.
G
Okay,
so
just
I
mean
I
I,
there's
not
often
those
kind
of
suggestions
in
the
in
the
semantic
conventions
right.
It's
really
there
to
say,
like
I,
did
the
best
place
of
doing
this
as
XY
and
sets
so
I
would
I
would
leave
it
out
or
leave
it
like.
It
is
right
now,
but
but
make
it
optional
and
yeah
and
also
remove
the
requirement
for
for
the
uui
for
the
you,
l
I,
don't
remember
right
now.
It
was
called
this
timestamp
based
ID.
G
B
Okay,
sorry
folks
I
have
to
chops
good,
seeing
everyone.
E
I
I
did
it
probably
I
just
wanted
to
follow
up
on
that
issue
that
you
had
created.
E
If,
if
I
remember
correctly,
I
think
the
only
Small
Change
we
considered
making
was
to
not
to
to
basically
remove
the
arrow
from
event
certificate
to
the
log,
API
and
and
then
rest
correct.
A
Correct,
that's
also
how
I
remember,
and
then
there
was
the
the
part
that
we
didn't
settle
on
was
whether
whether
the
events
SDK
depends
on
Vogue
API.
E
I
think
I
think
that's
an
implementation
detail
of
the
events
SDK.
So
we
said
it
will
leave
it
out
and
also
Jack
raised
the
a
confirmed
that
the
force,
flush
and
shutdown
may
not
be
easy
to
implement.
If
you
use
the
log
API
so
well,
it
remains
to
be
seen
how
the
events
SDK
implementation
would
happen.
A
So
from
what
I
understand,
everybody
agrees
that
events
API
should
not
depend
on
log
SDK
I
think
we
all
agreed
on
that,
and
this
is
what
the
issue
was
created
for
so
I
think
we
can
conclude
with
that
mark
this
issue
down
and
create
another
issue
which,
where
we
discuss
okay,
so
what's
the
exact
structure
of
events
API
and
events
SDK
and
how
they
are
implemented,
what
they
depend
on,
but
the
conclusion
of
this
one
is
that,
yes,
we
say
that
events
API
does
not
depend
on
log
SDK,
directly.
A
D
Yeah
and
then
once
we
get
into
the
implementation,
we
can
figure
out
the
whether
or
if
we
need
to
flush
the
force
flush
issue
from
a
client
perspective.
Once
we
hand
it
over
to
the
logging
implementation
that
should
already
handle
the
unload
functionality,
so
at
least
on
the
browser
perspective,
but
for
other
environments
it
may
or
may
not
be
an
issued
like
if,
if
the
event,
SDK
implementation
is
this
great
password,
then
I'm
struggling
to
think
why
we
would
need
the
event
API
to
say.
I
now
want
to
flash
everything.
E
I
think
it
might
be
needed
in
the
case
of
mobile
apps
and
have
where,
if
you
close
the
app,
let's
say
for
some
reason
when
you
are
shutting
down.
Let's
say
your
mobile:
your
system
will
but.
D
E
F
D
E
So
I
said
just
skipping
those
two
methods
done
in
flush,
but
when
using
the
log
API
you
know
those
those
methods
could
be,
you
know
not
implemented.
You
know,
don't
do
anything.
D
Yeah
well
or
the
your
special
delegates,
or
something
that
you're
it
reaches
into
the
instance
that
it's
passed
or
it
means
as
an
event
protocol
that
says,
trigger
this
event
and
that
login
I
don't
know
I'm
crying
out
ideas.
E
But
again
we
they're
in
the
spec.
Today
there
is
an
events:
API
dot,
MD
I
think
there
is
an
API
empty
that
refers
to
log,
should
we
rename
them
so
that
the
log
API
and
an
event
API
and
then
there's
a
log
SDK
and
event
SDK
for
separate
documents.
A
I
think
so,
right,
yes,
based
on
what
we
just
agreed
on,
we
need
to
change
that
event.
Dash
api.md,
not
to
depend
not
to
say
that
it
uses.
Let
me
use
this,
let
me
see
what
does
it
say
right
now?
We.
E
A
H
I
have
a
one
one,
just
one
related
related
question
or
comment
since
we're
removing
the
dependency
from
from
the
event
API
to
the
logger.
Then
the
current
spec
calls
the
the
class
or
the
the
thing
that
emits
events,
event
logger
and
Jack's
implementation
projects
prototype.
Instead
of
that
now
use
this
event,
emitter.
H
We
also
have
we
discussed
this
in
the
JavaScript
seg
and
event.
Emitter
conflicts
with
internal
API,
that's
also
called
event
emitter,
so
the
preference
that
I
would
be
to
call
it
something
else.
So
we
don't
have
to
maybe
like
decide
right
now,
but
just
something
to
think
about
like
or
my
question
would
be
like.
What
do
we
want
to
call
it
call
it
now.