►
From YouTube: 2022-01-13 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
B
D
D
E
Yeah,
so
I
have,
I
have
two
things:
two
things
that
I
had
on
my
on
the
agent
that
I
know
of
one
is
yesterday.
We
talked
about
the
service
name
attribute
in
the
specs
meeting
and
ted
was
going
to
join.
This
meeting
sounds
like
he
can't
make
it,
but
there
is
maybe
just
really
quick.
Do
we
have
a
consensus
that
using
service
dot
name
doesn't
make
sense
for
us.
D
Of
course
it
it
doesn't
make
sense,
but
I
was
thinking
later
that
I
think
I
think
the
biggest
point
is
what
john
mentioned
at
the
end
yesterday,
which
is
the
cost
of
educating
people
that
it
is
not
really.
You
know
what
it
means
in
in
this
context.
D
So
if
we
were
to
still
go
ahead
with
it,
then
maybe
you
know
it
should
I
mean
no
amount
of
documentation
would
be
sufficient,
but
in
you
know,
if
documenting
is
what
we
can
do,
then
maybe
we
could
consider
an
application
as
a
virtual
service,
where
you
know
it
spread
out.
The
instances
of
this
service
is
spread
out
across
you
know,
multiple
end
users.
D
And,
if
put
that
way,
you
know,
maybe
it
makes
some
small
sense.
It
has
some
equivalence
to
a
back-end
service
where,
when,
when
you
look
at
a
service
to
service
interaction,
typically
the
same
service
instance
will
make
multiple
calls
to
other
services,
because
it's
servicing
multiple
requests
simultaneously,
whereas
in
an
end
user
case
it
is
making
requests
on
behalf
of
only
one
end
user.
B
One
so
because
service
name
is
currently
mandatory.
What
we
have
done
on
the
splunk
side
is
provide
in
our
configuration
code
for
at
least
for
android,
and
I
think
this
is
true
for
ios.
I
hope
it's
true
for
ios.
We
let
them
set.
The
like
user
sets
the
app
name,
but
then
we
write
that
as
service
name
back
behind
the
scenes,
it's
not
great,
but
at
least
it
provides
an
api
that
the
user
it
will
be
familiar
to
the
user.
It
won't
be
confusing.
B
D
No
at
the
api,
it
will
be
called
as
an
app,
so
so
the
api
would
say
set
app
name,
but
in
the
underlying
data
model
you
know
we
would
still
be
sending
service
dot.
Name.
E
Yeah
I
mean
we'll
still
have
the
issue
of.
We
can't
use
app.name
to
identify
the
resource
using
using
the
app
attribute
anymore.
D
I
mean
we
could
use
it's
just
that
in
the
it's
not
going
to
be
a
standard.
F
D
So
I
would
rather
leave
it
with
service
name,
have
one
confusion
rather
than
two.
G
So
it's
not
clear
to
me
if
his
statement
or
his
assertion
that
a
service
name
should
always
be
present
is
actually
accurate,
at
least
in
the
case
of
metrics.
In
the
case
of
traces,
I
think
he
is
actually
he's
correct.
G
Morgan.
Do
you
know
what
what
the
resource
looks
like
in
those
cases
like
when
the
collector
tgrand
would
be
the
best
person,
because
I
actually
had
to
ask
on
the
spec
call
just
to
clarify
that
there
was
no
service
name,
but
but
everyone
said
yes,
there
is
no
service
name
when
those
are
captured,
so
there's
there's
some
sort
of
shape
of
a
resource,
that's
infrastructure
only
with
no
service
attached.
So
I
just
wonder
why
we
can't
do
the
same
thing
here.
G
I
I
just
pinged
ted
by
the
way,
to
ask,
if
he's
jordan,
because
he
said
he
was,
but
if
he's
not
like,
I
don't
want
to
turn
this
into
another
debate
at
the
huge
spec
call.
But
anyway
sorry,
no
I'll
stop
interrupting
yeah.
He
told
me
yesterday,
you
couldn't
make
it
today.
Oh
shoot.
Okay,.
B
E
Okay,
so
suppose
that
discussion
will
continue
later
on
the
the
other
topic
that
I
that
I
had
went
to
to
circle
back
to
was
zero
duration
spans.
E
We
started
that
discussion
last
week,
basically
considering
whether
we
could
use
zero
duration
spans
for
client-side
events.
E
E
Okay,
can
you
see
the
the
plan
document?
Yes,
okay,
so
okay,
so
we
did
out.
We
did
we
did
this
while
ago
we
wrote
down
some
examples
of
events
that
you
think
we
would
be
collecting
from
browser
and
mobile
and
if
I,
if
I
just
go
through
them,
I
don't
seem
to
see
many
of
them.
That
would
actually
be
parents
to
other.
D
Well,
I
think
the
the
by
using
spans
it
allows
us
to
have
multiple
spans
in
a
trace,
but
you
could
always
have
just
one
span
in
a
trace
as
well.
D
There
are
examples
there
are
use
cases
where
a
parent
child
or
a
causal
relationship
is
is
required.
Is
it
feasible
to
implement
that.
D
So
out
of
these
examples,
are
there
let's
say
you
know
you
click
a
button
and
there
is
a
screen
change
so
in
in
the
web
world
in
the
browser
world.
Do
you
think
it's
possible
to
capture
that
context?
D
D
B
B
You
don't
have
to
propagate
via
the
context
you
could
propagate
manually
by
passing
the
span
around.
But
it's
not
it's
not
very
pretty,
but
it
can
be
done.
E
Yeah
I
mean
so
so.
There
is
an
example
of
the
the
context
propagation
for
for
browse
for
interactions.
E
So
when
you
click
on
something
you
can
you
can
in
the
browser,
you
can
click
on
a
trace
trace
all
the
all
the
execution
that
was
spawned
from
that
callback
or
from
that
function.
E
E
E
E
But
they
can't
they
don't
have
their
own
id,
so
they
can
be
like
the
parent
of
something
else
happening,
but
things
like
you
know
things
like
when
there's
like
uncaught
error
like
that,
will
not
that
will
not
cause
something
else
likely
right
or
visibility.
Change
will
not
cause
something
else.
Be
parent
or
network
change.
Network
connectivity
change
would
not.
C
So
we
had
like
a
case
like
that
that
we
had
a
lot
of
javascript
errors
which
were
caused
by
a
maybe
it's
not
related,
basically,
a
span,
a
request
didn't
load,
and
so
some
javascript
was
not
present
and
then
down.
The
line.
D
So
this
is
a
problem
outside
of
client
set
telemetry
as
well
right
like
in
in
the
server
side,
node.js.
E
Yeah,
I
I
guess
I
suppose
node
instrumentation
would
have
a
similar,
similar
issues
yeah
anywhere.
There
is
an
async.
B
Would
it
that
make
sense
to
have
the
model
be
one
where
we
could
capture
causality
even
for
I
mean
there's
no
problem
having
a
single
zero
duration
span
as
the
only
thing
in
the
trace
and
it's
not
harmful
that
the
sdks
will
handle
that
back
into
handle
that
just
fine,
but
if
there
are,
if,
if
we
find
a
case,
where
maybe
let's
say
on
android
or
on
ios,
where
we
can
track
the
causality
for
these
for
some
of
these
things,
if
we
had
chosen
to
do
logs
rather
than
spans,
then
we
will.
B
We
won't
have
a
way
to
do
it.
So
that's
one
thing
to
consider:
I
don't
it
may
or
may
not
be
worthwhile,
like
maybe
the
causality
we
could.
We
could
say
that
causality
just
doesn't
matter
in
these
cases
and
what's
more
important,
is
the
flow
of
events
that
happen
throughout
a
session.
D
So,
in
that
case,
would
they
still
be
zero
duration
spans
are?
Are
we
also
open
to
having
spans,
which
are
not
a
zero
duration.
B
Well,
there
are
definitely
going
to
be
things
that
aren't
zero
duration
right
like
if
we
can
track
when,
like
in
android,
it's
very
trivial
to
track
when
a
page
or
when
a
screen
starts
being
loaded
and
then
and
to
span
when
it
is
finally
visible,
that's
trivial
to
do
in
android.
H
And
I
think
that's
the
same
case
for
document
loads
as
well
on
the
website
right
like
there's
a
clear
start
and
end
to
it,
and
then
there
is
a
there
could
be
a
causal
relationship
for
resources
around
it
too.
So
you
can
actually
create
that
tree
structure
that
you
want.
So
there's
definitely
a
use
case
for
that
that
are
we
overloading
that
use
case
for
the
span
too
much
today,
with
all
these
lcd
fid
cls
that
I'm
not
sure.
E
And
I
think
what
network
network
network
calls
obviously
also
and
even
like
interactions
like
down
interactions,
would
probably
are
probably
better
represented
as
spams,
because,
potentially
you
can,
you
can
have
duration
or
you
can
capture
duration,
like
the
existing
instrumentation
in
the
js
sdk.
Does
that.
B
B
G
B
But
should
we
use
fans
for
all
these
events
and
some
of
them
will
have
duration?
Some
of
them
won't,
and
I
would
guess
that
some
of
these
things,
where
there's
analogs
between
web
and
and
mobile,
that
in
one
case
they
may
have
duration
in
another
case
they
may
not
like
they
may
not
be
captureable
on
on
the
web,
where
it
was
on
android
or
vice
versa.
B
E
Yeah,
I
think
I
think
one
thing
that
I
would
like
to
at
least
come
down
to
is
like
whether
or
not
we
need
to
pursue
the
discussion
about
about
ident
the
semantic
conventions
on
on
logs
right.
So
like
are
we
gonna?
Are
we
not
need
logs
at
all.
B
B
G
B
Santosh
has
brought
this
up
in
the
past.
Sorry,
though,
let
me
just
give
it
one
second
as
well
in
the
past,
if
we
do
have
some
logs,
that
are
events
and
some
logs
there's
just
logs,
how
do
we
like
how
do
back
ends
distinguish
between
those
two
things.
I
The
dimension
I
wanted
to
highlight
is
that
specifying
this
kind
of
behavior
like
do?
We
represent
those
zero
duration,
events
as
spans
or
or
log
entries.
It
should
belong
in
the
data
model.
Doesn't
it
and
but
tracing
site
doesn't
have
any
data
model
defined
in
the
spec?
Only
logs
and
metrics
are
so
we
might
need
to
stitch.
I
I
Well,
I
meant
that
most
of
the
stuff
that
we
aim
here
is
aimed
after
semantic
conventions.
It
would
be
an
addition
or
a
change
in
semantic
conventions,
but
this
kind
of
agreement
that
we
are
discussing
here
is
very
fundamental
of
how
do
we
represent
the
events
and
the
the
natural
place,
at
least
in
my
mind
where
it
should
belong,
is
a
data
model,
but
tracing
doesn't
have
a
data
model
in
the
spec
as
opposed
to
logs
and
metrics.
So
there
is
kind
of
this
nuance
to
the
to
the
eventual
agreement.
D
So
the
question
is
once
when
we
receive
these
spans
on
the
back
end.
How
do
we
know
that
these
need
to
be
processed
by
an
even
processing
system
versus
a
trace
processing
system
or
which
are
somewhere
to
distinguish
between.
D
D
E
D
Actually,
going
back
to
the
the
previous
discussion
on
starting
with.
D
You
know
not
worrying
about
causal
events
like
multiple
spans
in
a
trace,
but
just
leaving
it
as
a
possibility.
In
case
we
come
across
situations
where
it
is
possible
to
implement
them,
I
think,
even
to
start.
I
think
we
would
need
at
least
like
two
or
three
examples
clearly,
so
that
you
know
we
can
make
a
case
for
ourselves
that,
yes,
there
are
situations
where
this
is
possible
to
implement,
and
that's
why
we
are
choosing
the
the
tracing
signal
for
representing
client-side.
D
B
Well
one
so
one
concrete
example
that
doesn't
it's
not
any
of
the
events
that
are
listed
here,
but
it's
business
events
it's
certainly
possible,
although
I
will
say
that
the
the
way
that
I've
modeled
these,
at
least
in
our
examples,
we've
written
for
the
splunk
chrome
instrumentation-
is
not
as
zero
duration
spans
just
as
very
short
duration
spans
because,
like
let's
say
the
user
clicks
a
button,
that's
like
a
checkout
button
from
a
user's
perspective.
That's
essentially
instantaneous
right.
It's
just
like
a
click
of
a
button.
B
The
button
click
itself
is
very
short,
but
you
can
actually
you
can
capture
that
button
click
and
then
put
a
context
block
around
the
next
calls
that
happen
right.
So
you
can
propagate
that
context
of
the
of
that
button
click,
the
checkout
action
from
the
user.
You
can
propagate
that
context
into
a
bunch
of
asynchronous
calls
that
happen
even
and
then
the
the
actual
outer
span
and
context
get
closed
right
away,
but
the
context
has
been
propagated
to
the
async
into
the
async
calls.
D
Do
you
know
any
such
possibilities
in
the
in
the
back
end
like
in
the
in
the
current
world
outside
of
client
side
telemetry?
Do
you
know
this
as
a
whether
there
are
any
use
cases
similar
to
this,
but.
B
I
think
any
any
async
framework
ends
up
working
out
this
way
like
if
you're,
if
you
have,
if
you
have
some
sort
of
request
that
comes
in
that
kicks
off
a
bunch
of
background
work,
but
the
request
then
responds
the
user
gets
a
response
almost
immediately
that
there
is
something
going
on
that
there's
something
has
been
kicked
off
like
there.
That
can
be
that
that
actual
request,
http
request,
can
be
the
parent
of
then
a
series
of
whatever
has
to
happen.
D
But
it
feels
like
this
is
mostly
applicable
in
you
know,
in
a
business
context,
as
in
a
customer
defined
context
propagation,
as
in
the
the
when
the
the
chain
is
going
to
end
or
or
which
events
to
actually
put
in
this
chain
cannot
be
automatically
detected,
it
has
to
be
customer,
provided
so
so
this
would
just
stay
in
the
api
level
and
and
and
not
be
part
of
any
automatic
instrumentation.
B
At
least
that
example
that
I
came
up
with
off
the
top
of
my
head-
yes,
but
I
think,
but
I
think
my
my
older
point
may
hold,
which
is
we
have
at
least
some
cases
where
you
do
like
a
business
event.
We
do
want
to
be
able
to
propagate
the
causality
in
the
context.
B
So,
if
we're
going
to
model,
if
we
need
to
be
able
to
model
these
business
events-
or
I
know
another
term,
that
is
occasionally
used
as
a
work
like
a
business
workflow,
if
we
need
to
model
those
as
spans-
and
some
of
them
may
have
extremely
short
duration,
because
they
just
end
up
initiating
a
bunch
of
asynchronous
work,
then
maybe
all
events
need
to
be
spanned
so
that
this
case
can
be
included
unless
we
decide
to
model
kind
of
business
events
as
a
separate
thing,
it's
different
than
the
other
events,
which
is
another
option,
but
would
definitely
add
complexity
to
like
how
does
one.
D
Sure
yeah
yeah
now
I
think
business
events
certainly
is
very
exciting
requirement.
I'm
sure
it
will
be
very
helpful,
but
I
think
maybe
we
could
think
through
and
maybe
next
time
we
made
you
know.
I
think
it
will
be
good
to
have
some
concrete
examples
where
the
the
default
instrumentation
could
capture
some
causal
events.
B
D
B
D
Then
martin,
maybe
we
could
think
about
examples
on
the
browser
side,
too.
B
B
If
we,
if
we
just
say
you
know
we're
going
to
model
everything
that
spans,
it
makes
it
easy
to
write
instrumentation,
because
you
don't
have
to
worry
very
much
about
this
kind
of
tricky
decision.
We
spent
a
lot
of
time
talking
about
because
it's
not
easy
right.
Maybe
we
just
say
it's
simple:
it's
straightforward
instrument,
instrumentation
authors,
don't
need
to
worry
too
much
just
model
everything
as
a
span
or
or
a
log.
If
it's
like
really
a
log,
then
then
write
a
log,
but
otherwise.
B
Think
you
all
have
a
lot
more
experience
than
I
do
on
writing.
Instrumentation,
especially
well.
I
have
zero
in
the
browser
at
all.
Like
is
this.
Is
this
the
kind
of
decision
that
you
want
to
have
to
think
about
when
you're
writing
instrumentation,
or
would
it
be
easier
to
just
say,
hey
we're
going
to
write
it,
we're
going
to
design
an
api
for
writing
client-side
instrumentation
and
in
the
end
of
the
at
the
end
of
the
day,
everything
that
it
emits
is
going
to
be
spans?
B
B
We
don't
necessarily
just
need
to
say
our
only
api
is
the
open,
telemetry
tracing
api,
like
we
could
design
more
easy
to
use
apis
for
instrumentation
authors,
they've
done
that,
like,
for
example,
in
the
java,
the
java
instrumentation
group
for
the
back
end
they've
spent
a
huge
amount
of
time.
Writing
an
api
specifically
for
instrumentation
authors
to
do
instrumentation,
which
is
a
higher
level
api
than
the
actual
just
tracing
and
metrics
api.
B
B
So
it
would
be
easy
for
any
a
client-side
sdk
author
to
just
say,
hey
every
we're
going
to
model
everything
as
fans,
rather
than
trying
to
figure
out
how
like
when
to
decide
to
shun
things
into
a
logging
sdk
and
when
to
put
them
into
the
tracing.
Sdk
like
the
sdk,
will
be
a
lot
simpler
to
maintain
and
manage
if
all
it
does
is
emit.
Spams.
B
And
at
the
end
of
the
day,
I
think
maybe
just
this
just
occurred
to
me.
Maybe
the
important
consideration
is
not
even
the
instrumentation,
but
the
back
ends
like
are
the
back
ends
going
to
be
happy
like
analyzing
everything
in
terms
of
spans
or
the
back
ends.
Do
they
want
to
have
some
things
as
logs?
D
So
in
in
your
current
implementation,
the
android
spans,
which
are
events-
how
are
they
distinguished
from
other
network
spans
so.
B
I'd
say
effectively:
it's
done
via
symantec
conventions,
some
of
which
are
the
open.
Telemetry
semantic
conventions
like
the
http
client
spans,
have
a
very
well
determined
semantic
set
of
semantic
attributes
and,
like
the
name
of
the
span,
is
well
well
known
and
well
determined.
E
Okay,
so
one
one
implications
I
can
think
of
is
is
sampling
if
you
started,
if
you
start
a
single,
you
know
single
span
like
you
can
have
it
so,
okay,
I
want
to
think
about
some
downsides
so
or
like.
D
The
sampling
is
is,
if
we
think
about
sampling
now
I
I
think
we
will
end
up
losing.
You
know
business
functionality
that
is
desired,
but
instead,
if,
if
sampling.
D
Discussion
is
given
the
current
situation
as
requirements.
Then
the
sampling
strategies
have
to
be
designed
to
handle.
You
know
the
the
current
data
model,
so
I
think
I
would
look
at
sampling
later.
B
B
There's
probably
very
little
use
for
client-side
sampling,
like
the
amount
of
data
generating
here,
should
not
be
so
much.
The
sampling
is
really
going
to
have
to
happen.
I
think,
on
the
back
end,
the
back-end
side,
where
you
decide
how
much
you
want
to
keep
and
how
many
sessions
you
want
to
keep
that
sort
of
thing
or
it
could
be
at
the
client
side
like
in
a
very
gross
like.
Are
we
gonna?
Are
we
gonna
record
this
session
at
all
sort
of
decision,
rather
than
an
individual
trace
by
trace
decision?
I
think.
C
C
In
browser
we
sampled
by
session
and
browser,
makes
the
decision
that
c
session
is
sampled
and
doesn't
send
any
data
for
that
session.
I
think
that's
how
it
is.
D
Speaking
of
sessions
so
john,
the
use
case
that
you
mentioned
earlier
about
putting
multiple
events
in
a
given
trace,
async
events,
business.
D
D
But
we
could
have
custom
sessions.
I
mean
just
just
a
thought
that
you
know
that
situation
could
be
modeled
as
a
as
a
custom
session
as
well.
D
So
whatever
logic
and
apis
we're
going
to
come
up
with
for
sessions,
you
know
could
be
used
for
that
situation.
D
Across
multiple
screens,
yeah
do
you
and
there
are?
There
are
two
ways
you
know
we
could
model
this.
You
know
you
could
model
this
as
multiple
events
in
a
given
session
or
multiple
events
in
a
given
trace.
H
Yeah,
but
I
mean
that
trace
would
fundamentally
be
running
for
the
whole
session,
then
right
in
theory,
it
could
extend
for
the
absolutely
entire
duration,
because,
let's
say
you
want
to
model
from
the
app
start
to
or
like
from
the
first
page
that
was
load
now
it
depends
on
whether
you're
talking
about
web
or
mobile
right.
It
depends
on
like
a
mobile
app.
You
can
actually
decide
from
an
instrumentation
standpoint
when
the
app
started
to
when
the
session
completely
ended,
but
in
web.
Those
business
events
will
likely
happen.
E
D
Only
in
the
case
of
single
page
applications
right,
if,
let's
say
it's,
not
a
single
page
application,
you
know
every
transition.
Page
transition
brings
out
a
completely
new
html.
C
H
D
Remember
we
are
talking
about
business
flow
where
you
know
we
cannot
detect
the
events
in
this
session
automatically.
This
has
to
be
customer
defined.
D
D
So
this
example,
you
know,
will
go
through
multiple
pages,
multiple
screens
and
the
underlying
technology
to
carry
forward
the
binding.
You
know
whether
the
trace
context
or
the
session
context
you
know
has
to
be
the
logic
to
carry
forward.
Has
internal
logic
to
carry
forward
has
to
be
the
same.
R
can
be
the
same.
H
And
what
is
easy
for
the
the
engineer
to
define
too
right,
like
I
think
it's
not
like
it
needs
to
be
abstracted
enough.
D
D
Tracing
only
for
those
specific
situations
where
it
is
easy,
basically
have
both
a
trace
api
for
client-side
telemetry,
as
well
as
an
events
api
that
is
not
based
on
spans.
H
But
is
there
any
would
there
be?
Would
it
be
bad
to
have
it
as
a
zero
duration
span?
In
the
context
of
the
whole
session,
like
at
the
end
of
the
day?
It's
still,
it's
still
a
step
in
the
whole
session
that
you
would
want
to
look
at.
Does
it
need
to
be
discrete
from
sort
of
all
of
your
http
calls,
like
you
still
kind
of
want
to
see
it
in
that
context,
in
the
same
timeline
right.
D
So
let
me
ask
this
in
a
different
way,
so
how
would
we
want
to
model
a
session
on
you
know,
assuming
we
have
settled
on
zero
duration
spans
no
using
of
log
records
and
using
the
trace
apis
in
this
situation?
How
would
we
want
to
model
a
session?
So
would
it
be
a
new
attribute
that
defines
the
session
id
or
would
we
want
to
use
the
the
trace
context
as
the
one
that
identifies
the
the
business
context.
B
We
wouldn't
want
to
use
trace
a
span
to
represent
a
session
because
they're
going
to
be,
it
can
be
very,
very
long
and
it
doesn't
make
sense
they'll.
Never
they
may
never
end
right
and
they
may
never
end.
At
least
I
don't
think
we
want
to
do
that.
What
we've
done
at
splunk
is
we
just
there's
an
attribute,
that's
generated,
that's
the
session
id
that
then
gets
attached
to
every
span.
G
D
Okay,
so
then
there
will
be
a
separate
session
api.
There
will
be
in
addition
to
the
the
trace
api
and
for
a
customer.
You
know
they
could
go
with
either
of
them
to
to
represent
their
business
flow.
B
B
But
maybe
that's
maybe
that's
not,
maybe
maybe
we
want
to
have
two
ideas,
one
of
which
is
kind
of
something
that
can
be
counted
for
billing
purposes
and
something
and
then
there's
something
that
is
maybe
a
more
user
or
an
application
developer,
oriented
session
idea
which
could
be
shorter
if
they
want
to
model
it.
That
way,
I
don't
know
I
don't.
I
don't
have
any
great,
perfect
ideas
on
this.
It's
just
I'm
thinking
out
loud.
D
H
Yeah
and
like
I
think,
session,
also
confused,
especially
when
we
talk
to
sort
of
end
users,
sometimes
like
a
session,
tends
to
confuse
a
little
bit
also
because
everyone
thinks
it's
sort
of
their
back-end
authentication
session,
whereas
it
could
actually
be
completely
different.
So
it
depends
on
what
what
we
want
to
define
as
a
session
for
the
hotel
world
like
is
it
from?
H
D
And
the
customer
could
implement,
you
know
their
logic
using
either
of
them.
So
I
think
we
need
to
have
some
clarity
in
the
guidance
on
which
approach
to
follow.
D
B
Yeah
I
mean,
I
think
this
discussion
of
session
is
something
that
we
need
to
have
like.
This
is
a
it's
a
big,
it's
a
big
deal
that
needs
to
be
sorted
out,
we're
not
going
to
get
it
in
the
next
eight
minutes.
I
don't
think,
but
definitely
I
think
it's
in
one
of
our
documents
right.
If
it's
something
we
need
to
sort
out.
H
Are
there
one
or
two
questions
that
we're
trying
to
answer
before
the
next
week
meeting
like
maybe
just
one
top
one,
so
we
can
all
think
about
it.
B
B
D
Yeah,
I
think
we
will
need
concrete
examples,
then,
both
on
the
mobile
and
web.
B
B
E
Okay,
I
can,
I
can
get
that
started.
Maybe
I'll
just
share
yeah.
H
John,
just
a
quick
question:
does
that
make
sense
to
do
before
we
have
let's
say
10
examples
written
down
or
after
yeah?
I
think.
B
I
think
the
process
of
writing
the
otep
will
include
those
examples,
and
so
I
think
it's
it's.
I
think
it
for
me
at
least
it's
a
way
to
just
bootstrap
the
process
like
let's
go
wrong,
let's
write
some
stuff
down.
Okay,
thank
you,
which
I
think
we
have
a
lot
of
stuff
written
down
already.
I
just
think
we
need
to
transform
that
into
a
more
formal
document
that
we
then
would
present.
E
H
Martin,
just
a
quick
question:
where
would
it
be
helpful
to
write
down
these
examples
in
that
open
telemetry
plan
for
client
instrumentation?
Do
we
just
want
to
create
a
table
with
examples?
I
know
you
wrote
a
similar
one
for
log
record,
but
just
trying
to
see
how
we
could
help
crowdsource
the
examples
a
little
bit.
H
D
I
think
someone
mentioned
metrics
earlier
in
this
call,
so
I
I
just
remembered,
I
think
you
guys
had
you
you
wanted
to
check
with
the
specs
team
on
on
whether
to
represent.
B
Yeah
these,
I
think
these
things
are
great
things
to
to
include
in
that
write-up
and
I
think
we're
talking
about
things
like
browser,
measured
numbers
that
are
given
to
us
as
as
instrumental
for
the
instrumentation,
so
that
sort
of
thing
like
these
contentful
paint
and
that
sort
of
sort
of
numbers
yeah
yeah.
So
I
think
we
should
include
those.
I
don't
know
I
mean
we
could.
I
think
it's
up
to
us
to
how
we
want
to
model
them.
They
certainly
seem
sound.
B
C
B
But
then
we
might
also
want
to
record
a
span
or
maybe
a
log.
I
don't
I
mean
I
don't
know
whatever
we
decide
with
the
with
the
actual
session
attached.
B
Or
the
well,
if
the
metrics
sdk,
when
it
when
it's
complete
and
it
supports
exemplars
the
it
might
just
work
the
way
it
is.
You
record
the
metric
and
if
there
happens
to
be
something
in
the
context
of
span
in
the
context
it
would
get
associated
as
an
exemplar.
I
don't
know
if
that's
good
enough,
but
something.