►
From YouTube: 2022-03-10 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
Hey
man
good
morning
good
afternoon,
I
don't
quite
know
where
you're,
where
you're
at
good
evening
now,
oh
evening,
man,
you
totally
trumped
me
good
evening.
B
B
A
C
B
I
don't
know
about
ludmilla.
I
also
don't
know
really
what
you
what
you
talked
about
last
week
as
I
was
on
vacation
last
week,.
B
D
D
It
was
only
a
few
minutes,
but
we
can
maybe
extend
it
or
talk
about
it.
B
We
could
talk
about
it
because
I
also
just
sketched
something
just
to
give
us
some,
some
actual
sketch
some
idea
that
I
talked
about
this
ludmila
at
some
point
like
one
and
a
half
weeks
ago,
and
maybe
we
start
out
with
this
sketch
that
I
made
and
then
maybe
I'm
here
we
can
talk
about
pros
and
cons.
You
came
up
with
because
this
sketch
that
I
made,
I
think
it
actually,
there
is
a
different
solution
incorporated
there.
B
So,
let's
let's
go
through
that
first
and
then
let's
go
to
the
to
the
pros
and
cons
that
you
worked
out.
So
I
put
this
link
here.
I
just
got
like
put
up
some
diagrams
here,
and
this
is
just
like.
This
is
just
basically
capturing
something
that
I
know
miller
kind
of
brainstormed.
It's
it's.
B
It's
not
the
really
kind
of
having
major
proposals
just
to
kind
of
maybe
get
us
thinking
and
put
out
some
options
there,
and
I
divided
it
between
single
message
scenario
and
batch
scenario
and
what
I
basically
put
in
as
a
common
thing.
In
all
scenarios,
all
scenarios
have
a
published
span.
Basically
here
yeah.
This
is
the
producer
side.
B
B
Basically,
iteration
is
supposed
to
be
covered
by
this
publish
call,
and
the
idea
is
that
yeah
for
the
single
message
scenario,
with
no
badge,
I
think
in
the
ideal
case,
we
just
can
do
with
one
single
publish
span
here
and
link
this
to
like
the
receive
span
on
the
other
sides,
or
there
might
be
multiple
receive
expenses
if
the
message
is
processed
multiple
times.
B
So
that
is
just
trying
to
come
up
with
the
easiest
possible
solution
for
the
single
message
scenario
for
the
batch
scenario
there
is,
there
are
kind
of
sever,
several
kind
of
several
possible
solutions
here,
and
the
idea
is
maybe
to
give
some
kind
of
freedom
also
to
users
and
sdk
developers
and
not
just
force
them
to
always
do
it
the
same
way,
there's
pros
and
cons
to
giving
the
freedom
but
yeah.
Let's,
let's
I
have
three
scenarios
here
or
three
possibilities.
So
let's
walk
through
them
a
bit
and
discuss
the
first.
B
One
is
also
the
simplest
one
and
it's
just
having
a
single
published
span
for
basically
a
batch
of
messages.
So
there's
a
batch
of
messages
published,
but
there
is
only
one
span
for
this
whole
batch
and
there
are
basically
yeah
multiple
receive
spans
for
different
messages
linking
to
this
same
span
here.
B
Then
there
is
this
other
other
scenario
where
we
basically
say:
okay,
we
passed
in
a
batch
to
this
publish
operation,
but
then
this
publish
operation
creates
like
a
dedicated
span
for
each
single
message,
so
here
we
basically
have
to
publish
operation
again
and
during
these
publish
operations
there
are
create
spans
created,
and
basically
this
span
here.
Each
great
span
is
dedicated
to
a
single
message
and
this
creates
spent
in
links
to
receive
spends.
B
That's
quite
that's
a
quite
more
powerful
modeling
than
we
have
here,
because
here
we
actually
see
okay,
how
much?
How
many
different
messages
do
we
have
and
we
can
correlate
each
receive
span
with
with
a
particular
message,
whereas
here,
when
we
just
look
at
the
structure,
we
actually
don't
know
those
two
receive
spans.
Are
they
processing
different
messages
or
are
they
processing
the
same
message?
B
We
cannot
say
without
looking
at
the
attributes
first,
here
it's
pretty
clear
and
then
there
is
the
last
one
that
is
also
some
capability
that
we
want
to
give
or
provide
to
the
user
that
the
user
might
not
want
to
have
this
create
spans
created
automatically,
but
the
user
user
might
want
to
want
to
create
this
creation
context
or
this
context
that
is
passed
on
a
message
by
themselves
and
pass
it
along
with
the
message
in
the
published
call,
and
that
is
modeled
here,
so
basically
the
user
themselves.
B
B
B
So
basically,
this
link
goes
to
different
kind
of
spans
in
different
scenarios.
So
I'm
not
I'm
not
sure
how
elegant
or
nice
that
is
so.
You
are
curious
about
your
your
thoughts
about
that.
D
I
think
that
in
the
single
public
span,
so
this
publisher
span,
it's
not
only
published
it's
like
publish
and
create
a
combined
into
one
spam
semantically.
So
I
don't
yes.
B
B
And
I
think
where
it's
interesting,
then
here
it's
when
it
goes
down
to
the
details
and
we
we
talk
about
okay,
what's
the
span
kind
which
span
here
actually
is
the
producer
span,
and
I
think
here
in
this
scenario
for
sure
the
published
span
will
be
the
thus
that
will
have
this
mankind
producer.
Here.
Probably
the
bubble
span
will
not
have
the
spanking
producer,
but
the
creates
fans
will
have
this
mankind
producer.
B
So
there's
some
kind
of
yeah,
interesting
details,
then
later
on
to
to
consider
when
we
come
actually
the
details
of
like
putting
attributes
on
the
spans
and
but
it
also
makes
sense
when,
when
we
see
it
in
america
way,
we
say.
Okay
in
this
case,
just
those
spans
or
the
great
spans
are
collapsed
into
the
published
span.
And
in
this
way
the
published
span
basically
becomes
the
producer
span,
because
it
just
inherits
that
more
or
less
from
the
create
spans
or
incorporates
that
from
the
create
space.
E
B
B
B
In
this
third
case,
the
user
itself
creates
some
span
and
and
passes
the
context,
along
with
the
message
into
the
publish
call,
because
we
want
to
give
this
flexibility
to
users,
because
yeah
the
a
message
might
be
created
way
before
it's
published
might
be
even
like
created
in
another
other
thread,
or
I
mean
in
the
worst
case,
even
in
other
process,
and
we
want
to
kind
of
give
this
flexibility.
That's
also
something
like
miller
said.
D
E
B
It's
yes,
it's.
E
Okay,
great,
so
what
I
was
wondering
about
the
three
scenarios
is
whether
the
application
and
the
and
sdks
have
to
agree
upon
the
model
that's
being
used
or
what
would
the
rules
be
for
the
sdk
deciding
whether
or
not
to
inject
the
the
creation
context?
Would
it
look
to
see
if
one's
already
there
if
the
application
already
said
it,
and
if
so,
then
it
wouldn't
add
one
or
do
they
have
to
have
an
agreement
on
which
model
is
being
used?.
B
I
I
I
think,
they're,
I
think
in
this
case,
for
making
this
possible.
There
must
be
an
agreement
on
the
api
level
because
in
the
publish
card,
basically,
you
pass
in
an
array
of
messages
and,
along
with
this
array
of
messages,
you
would
also
need
to
pass
in
a
context
for
each
message,
because
they
just
will
not.
Every
message
will
not
use
the
same
context.
B
They
might
use
different
context
contexts
so
that
that
would
be
a
contract
on
the
on
the
at
the
api
level
of
this
published
call-
and
this
is
something
that
would
need
to
be
supported
by
by
messaging
sdks.
B
D
A
D
D
This
is
the
first
case,
so
me
and
zhao.
We,
we
wrote
some
pros
and
cons
and
we
can
add
more
so
the
pose
is
that
it's
a
very
simple
presentation
like
it's,
the
simplest
one
and
it's
very
cheap
because
we
don't
create
so
many
spends
right
and
the
cones
are.
D
A
D
Good
place
to
store
like
data,
which
is
per
message.
I
don't
know
message
id,
is
success,
partitions
things
like
that
and
actually
maybe
we
should
also
add
a
sampling
but
never
mind
for
now
and
yeah.
So
I
have
also
a
showed
last
week
as
some
examples
like
drawings.
So
this
is
for
the
simple
case
and
if
you
scroll
a
bit
down,
then
this
is
what
it
looks
like
in
a
batch.
D
So
we
have
these
sense
bands
and
we
have
delivered
and
practically
everything
is
possible,
like
one
deliver
can
can
point
to
a
multiple
sense
or
it
can
have
multiple
links
to
the
same
sand
or
it
can
like
everything
is
possible,
and
then
these
are
the
pawns
pros
and
cons
of
the
second
suggestion
and
yeah.
So
I
I
hope
it's
clear
like
I
think
it's.
If
we
look
for
the
most
there
like
a
logically
model
to
use.
I
think
that
creating
a
spam
per
message
is
like
that.
D
It's
very
well
correlated
with
with
what
like
we
want
to
model
and-
and
we
have
like
a
place
to
set
all
the
attributes
and
the
status
and
duration
and
everything
we
need.
We
have
this
spent
to
host
all
this
data
in
a
very
trivial
way
and
it
works
very
good
with
sampling,
because
each
message
carries
its
own
context,
so
we
can
set
some
messages
to
be
sampled
and
some
messages
to
be
non-sample.
D
D
We
can
follow
the
links
from
the
consumers
and
pick
a
specific
message
and
just
correlate
it
directly
when
we,
when
we
need
visibility
in
the
producer
side.
So
I
hope
it's
clear
and
the
cones
that
we
talked
about
is
that
it's
very
expensive.
We
can
potentially
create
a
lot
of
spends
and
we
have
feedback
from
mila
that
this
is
what
they
did
in
azure
and
people.
D
They
don't
find
it
convenient
like,
at
least
in
the
ui
level,
and
so
the
other
thing
is
that
in
open
telemetry
span
usually
represents
an
operation
in
the
system,
and
here
we
don't
track
any
operation.
We
just
use
it
as
a
place
to
store
data
and
and
create
a
context
and
the
last
one
that
yeah
it's
it's
probably
more
difficult
to
implement,
because
now
we
should
consider
if
the
context
is
generated
within
the
instrumentation
library
or
outside
or
maybe
they're
both
possible
and
it's
more
complex
to
implement
on
the
instrumentation
level.
D
And
then,
if
we
scroll
down
this
is
these
are
some
examples
of
how
it
would
look
like
that
I
showed
last
week
but
they're
not
important
and
if
you
scroll
to
the
third
option,
this
is
what
ludmilla
suggested
the
virtual
the
virtual
context.
D
So
yes,
so
it's
not
at
full,
I'm
sure
we
can
add
more
pros
and
cons,
but
the
obvious.
D
F
D
It's
like
we
have
most
of
the
pose
of
the
previous
one,
but
we
don't
create
a
spam,
so
it's
cheaper
and
then
the
cones
is
that
they
introduces
something
new
into
open
telemetry,
which
means
that
new
people
will
have
to
to
understand
and
follow,
and
it
makes
the
back
ends
much
more
complicated
and
and
and
still
we
don't
have
any
place
to
store
things
that
want
to
store
their
message
and
yeah.
So
so
I
don't
take
any
side
here.
D
It
doesn't
no
one
that
I
really
likes
and
then
I
want
to
suggest
that
if
people
want
to
add
more
pros
and
cons
now
like
live
so
we'll
have
like
something
summarized,
and
then
I
have
a
suggestion
on
how
to
to
like
what
we
should
do.
It's
only
my
suggestion
and
I
want
to
discuss
it.
But
what
do
you
think.
B
I
think
the
pros
and
cons
here
are
summarized
pretty
well,
there's
not
much
more.
I
can
think
about,
and
I'd
be
really
curious
to
see
your
your
proposal,
your
suggestion,
but
also
for
me
not
like
not
one
reason,
stands
out
here
as
the
obviously
best,
and
I
actually
think
the
more
I
think
and
the
more
we
talk
about
this,
the
less
convinced
I
get
that
we
in
our
semantic
conventions
can
say
okay
for
messaging
scenarios.
You
must
always
create
this
create
span
for
each
single
message
or
that
we
can
on
the
other
way.
B
We
can
also
not
say,
okay,
you
never
must
have
this
create
spam
for
it.
You
almost
must
have
this
one
spam
for
order
patch.
I
think,
and
that's
what
I
tried
to
put
into
so
in
the
in
the
other
solution
that
I
presented.
I
think
we
need
to
give
that
as
an
option
to
the
sdks
or
instrumentors
and
yeah
the
more
the
more
think
and
the
more
we
talk
about
it
less.
B
D
Yeah,
so
actually
that's
what
I
wanted
to
suggest
as
well,
that
we
will
allow
both
options
and
the
instrumentation
library
can
have
the
freedom
to
pick
one
or
it
can
support
both
of
them
and
user
can
configure
it
on
the
instrumentation
library
configuration
and
choose
which
one
they
prefer.
D
It
means
that
the
backends
and
uis
will
have
to
support
both
options,
which
I
think
is
acceptable
and
also
I
want
to
say
about
that.
The
second
option,
where
we
create
a
spend
per
message,
that
I
think
it
can
be
like
the
the
price
for
it
can
be
lowered
if
sampling
is
implemented
correctly.
D
So
we
maybe
we
don't
have
to
capture
all
the
spends
for
all
the
messages.
So
a
user
can
maybe
write
some
a
custom
sampler
or
we
can
think
of
a
way
that
the
sampler
can
be
used
to
reduce
this
number.
So
maybe
if
we
send
100
messages
in
the
batch,
but
we
want
to
sample
only
few
of
them,
like
I
don't
know
like
five
or
maybe
we
have
a
previous
sampling
decision,
we
have
like
a
pipeline
of
of
processing
and
we
already
have
the
previous
sampling
solution.
D
B
Say
I
also
agree,
and
I
like
that
we
came
to
two
similar
similar
conclusions.
B
And
there
are
just
some
words
to
the
virtual
context
model.
I
think
that
is
a
very
nifty
idea,
but
yeah
when
I
think
about
they
are
introducing
this
to
the
wider
hotel
community
and
requiring
our
backhands
to
support
this,
maybe
in
one
or
two
years,
but
it
seems
for
now
we
have
kind
of
lots
of
discussions
going
for
just
using
links
as
we
want
to
use
them.
B
So
if
we
don't
really
want
to
like
delay
this
work
with
yeah
with
an
unspecified
outcome,
I
would
suggest
not
to
pursue
the
virtual
context
path
for.
F
Yeah
I
mean
I,
it
seems
like
the
right
way
to
go.
I
think
that
the
only
thing
you
mentioned
like
making
things
like
a
configuration
option,
I
think,
for
the
end,
user
and.
F
B
I
mean
I
mean
I
would
say
I
I
would
leave
this
decision
to
do
implementers
actually
of
those
conventions
back,
I
wouldn't
from
our
side
specific
okay.
This
has
to
be
configurable,
or
this
has
not
been
configurable.
We
just
basically
present
supported
options
and
then
sdks
and
users
kind
of
pick
and
decide
what
to
use.
I
mean
we
can
still
say:
okay
from
hotel
perspective
yeah.
B
This
is
the
preferred
option,
so
we
I
think
that
that
we
could
say
that
is
okay,
if
possible,
use
this
option
and
that
might
then
prompt
the
sdks
to
have
this
as
the
default
thing
that
can
be
switched
off
and
replaced
with
something
like
this
in
cases.
But
I
think
we
should
make
two
strong
requirements
there,
but
we
should
rather
kind
of
represent
those
are
the
I
don't
know
two
or
three
options
that
are
there.
F
C
B
It
sounds
good,
and
actually
that
gives
me
something
to
work
because
then
I
will
work
on
try
to
spell
this
out
in
the
old
tap
until
next
time
and
then
maybe
our
people
can
review
review
the
go
tip
offline
and
we
can
then
maybe
continue
like
a
discussion
next
time,
but
it
seems
to
me
that's
a
pretty
kind
of
feasible
like
high
level
model
that
we
can
follow
here.
B
Because
then
yeah,
basically,
we
made
good
progress
on
this
one.
On
the
on
the
poor
scenarios,
there
is
still
some
discussion
pending
about
adding
links,
links
after
spank
creation.
I
think
the
discussion
goes.
The
discussion
goes
very
slow,
but
it
goes
in
a
direction
that
is
favorable
to
us.
B
It's
just
not
yet
completely
clear
to
me
what
how
to
best
proceed
there
I
tried
to
contact
the
doctor
who
gets
the
main
pushback
here.
He
also
he
he
softened
a
bit
so
he's
not
kind
of
he's,
not
kind
of
saying
strongly
no
anymore,
but
he
it
seems.
He
wants
to
embed
this
into
a
wider
discussion
about
links
in
general
and
I'm
I
I
tried
to
ping
him.
B
I
think
he's
on
vacation
now
try
to
clarify
what
is
actually
needed
there
if
he
would
need
like
an
old
tab
about
links
and
link
usage,
or
if
it's
just
some
kind
of
discussion
in
prs
that
we
need
I'm
not
sure
because,
there's
like
there's
many
questions
about
links
currently
floating
around
and
how
we
use
them.
And
I
mean
I
personally
think
it
might
be
good
to
just
have
an
old
tab
to
clarify
all
these
questions
and
make
clear
how
we
want
to
use
links.
But
then
yeah,
I'm
not
sure.
F
Yeah,
it
might
be
good,
I
bogdan
is
on
vacation.
I
I
also
talk
to
them,
and
hopefully
he'll
be
maybe
able
to
to
come
to
this
meeting
next
week
and
in
general
I
I
passed
it
on
to
the
the
tc,
like
a
request
that
we
have
a
like
a
permanent
tc
member
following
this.
This
group,
but
I
think
between
this
and
the
the
tuesday
meeting
a
tuesday
afternoon
meeting
we're
also
working
on
instrumentation.
C
B
C
F
Yeah,
we
could
try,
I
think,
he's
in
eu
time
zones
or
he's
going
to
be.
So
that's
why
he
can't
come
to
the
other
meeting,
but.
F
F
Yeah,
I
think,
yeah.
It
would
be
helpful
to
look
at
what
we're
trying
to
do
here,
plus
what
we're
trying
to
do
for
http,
which
is
using
links
in
a
very
different
manner.
It's
using
links
internally
within
a
trace
to
identify
relationships
that
aren't
parent-child,
but
not
trying
to
link
together
a
whole
bunch
of
traces
into
a
graph.
F
If
that
makes
sense-
and
it
seems
very
useful
for
that,
but
it
also
means
we
might-
it
might
be
important
to
have
things
like
say,
a
link
type
or
something
like
that,
so
that
back
ends
can
differentiate
between
these
things
because
they
might,
they
might
want
to
do
something
different
with
them.
F
Bill
said
she
was
able
to
to
get.
I
forget
his
name,
oliver,
maybe
but
one
of
the
people
who
worked
on
implementing
links
at
azure
to
come
to
next
tuesday's
meeting
to
kind
of
give
feedback
and
discussion
about
implementing
links
in
a
back
end
in
its
current
form
like
what
the
what
they
observe,
the
like
overhead
costs
to
be.
If
there's
any
changes
to
how
links
work
that
they
think
would
make
their
life
better.
F
B
That
sounds
great.
I
have
a
question
to
you
that
regarding
this,
this
sponsor
proposal-
I
think
you
brought,
did
you
put
up
this
pr
that
yeah
each
kind
of
work
group,
but
basically
you
say,
gets
a
sponsor
and
I
mean
I,
I
think
we
would
definitely
like
to
have
one
yeah.
If,
yes,.
C
F
Yeah,
I
think
I
need
to
I-
I'm
gonna
flush
it
out
a
bit
more
today
to
describe
what
the
role
of
a
sponsor
is
and
it
might
even
get
separated
we,
I
might,
it
might
even
end
up
separating
out
the
idea
of
a
sponsor
for
an
otep
from
a
sponsor
for
a
sig.
But
definitely
a
lesson
learned
is
that
when
we
have
spec
working
groups,
you
know
there
needs
to
be.
F
You
know
tc
members
following
the
work
of
participating,
otherwise
it's
too
easy
to
get
to
get
to
get
a
little
confused.
So
so,
luckily,
the
in
general,
the
tc
have
heard
that
so
there
should
be
somebody
from
the
tc,
hopefully
starting
next
week,
who
starts
joining
this
working
group
following
along.
B
So
I
I
think
we
wrapped
up
the
create
discussion
for
today
so
yeah,
it's
the
my
board
with
me.
I
will
write
this
down
and
put
this
in
words
in
the
old
tab
and
then
the
question
is
there:
we
will
go
next
here.
The
next
open
point
is
like
settlement
and
I'm
personally
not
even
sure
in
how
far
we
should
pull
settlement
into
version
1.0,
I'm
not
sure
if
anybody
on
the
call
has
like
ideas
or
requirements
or
preferences
about
that.
D
I
think
if
we
don't
talk
about
it
and
we'll
save
a
lot
of
implementations
and
it
will
make
a
very
difficult
life
for
beckons
and
their
uis,
because
there
will
be
no
standard,
people
will
just
implement
what
they
see
right
without
any
guidance.
D
And
I
think
it's
not
that
complex,
not
that
complex,
we
could
maybe
do
it
in
a
meeting
or
two.
B
That
makes
sense,
then
that's,
let's
put
this
in,
and
let's
make
this
the
next
topic
we
discuss
about.
So
I
think
for
today
at
least
I'm
not
prepared
to
talk
about
it
or
brainstorm
about
it.
I'm
not
sure
if
anybody
else
is,
but
then
we
can.
B
I
will
put
this
on
the
agenda
for
basically
next
week
and
maybe
we
can
brainstorm
and
think
about
it
until
next
week
and
then
and
then
discuss
what
we
would
want
to
provide
for
the
settlement
way
I'm
gonna
for
for
for
the
for
the
settlement
stage,
I
mean,
I
think
this
is
the
error
comes
in,
but
in
our
very
original
tab
we
worked
out
with
this,
make
two
main
scenarios:
the
the
first
one.
B
Basically,
the
the
message
based
settlement
and
the
second
scenario,
the
checkpoint
based
settlement-
and
I
think
this
that
the
scenarios,
basically
the
main
differences
of
those
scenarios,
are
here
in
the
settlement
state
like
either.
You
are
settling
a
message
individually
or
you
are
just.
You
are
forwarding
a
checkpoint
for
a
bunch
of
messages,
and
I
think
we
might.
B
Because
you
just
went
with
a
brainstorm
now,
I
think
the
first,
the
message-based
settlement,
that
is
pretty
easy.
The
settlement
operation
just
corresponds
to
usually
a
single
message,
whereas
with
the
checkpoint
based
settlement,
it's
it's
quite
a
bit
more
complicated
because
yeah
you
just
forward
the
checkpoint
and
you
in
some
cases
you
don't
even
know
what
what
the
order
messages
are
that
you
are
basically
putting
past
the
checkpoint
here.
E
I
think
one
of
the
challenges
we
might
run
into
as
well
here
is
this
feels
like
another
one
of
those
kind
of
zero
duration
spans
where
it's
more
of
an
event
than
something
that's
measured.
So
I
think
we'll
have
to
think
about
that
as
well.
D
There's
zero
length
in
sqs
when
you
delete
a
message
is,
and
it's
an
rpc
call
and
it
has
a
response
and
you
can
set
the
duration
to
the
time
until
you
get
the
response.
E
Okay,
so
when
you're
doing
yeah,
if
there,
if
I
guess
the
protocol
has
the
concept
of
an
acknowledged
acknowledgement,
then
I
can
see
it
measuring
something
in
there's
other
protocols
that
that
don't
do
that.
So
I
guess
that
would
depend
on
the
protocol.
D
So
it's
like
file
and
forget
you,
send
the
settlement
and
you
don't
know
it
was.
E
Yeah,
it's
up
to
the
the
underlying
sdk
to
to
maintain
state
and
and
ensure
that
that
that
it's
always
like
that,
it'll
resend
it
it.
When
there,
when
there's
gaps
in
the
stream,
it
will
remember
the
gaps
and
and
and
basically
make
sure
that
it
never
acknowledges
something
it
shouldn't,
but
that
it
it.
It
is
kind
of
a
fire
and
forget.
E
But
but
there's
under
the
hood,
there's
ways
of
making
sure
that
a
lost
message
is
not
treated
in
the
wrong
way.
B
I
mean
I
think
we
have
like
an
operation
here
with
iteration
in
the
sense
that
for
every
settlement
operation
I
mean
the
user
does
something
they
call
like
an
api
call
to
say:
okay,
settle
this
message
or
forward
this
checkpoint,
so
that's
usually
some
kind
of
operation
that
has
like
a
duration,
and
we
can
create
a
span
for
that.
As
I
think
what
is
the
main
unknown
here
is
and
yeah
I
mean
disregarding
what
happens
under
the
hood.
B
That
is
definitely
protocol
specific
and
can
have
a
duration
or
can
no
have
no
duration,
but
I
think
usually
what
the
user
sees
and
what
we
can
measure.
There
is
some
kind
of
span
there
that
we
can
create,
but
what
I'm
not
sure
is
then
how
to
best
integrate
this
with
the
other
trace.
How
do
we
know
with
the
settlement
operation?
B
Which
messages
are
actually
settled
with
that
operation?
It
might
be.
It
might
be
easy
in
the
thing
in
the
in
the
message
settlement
scenario:
there
you
just
have
here
one
message
that
you
can
link
to
this
settlement
operation,
but
with
the
checkpoint
based
settlement.
I
think
it's
much
harder
and
maybe
sometimes
even
impossible,
to
find
out
what
messages
are
or
kind
of
basically
move
past
the
checkpoint
when
forwarding
it.
D
B
B
Okay
and
then
then
I
think
actually
once
I've
spelled
this
out
here
and
I
think
here
then
in
in
this
area.
Here
we
have
figured
out
all
the
spans
that
we
are
gonna
advise
to
create
within
a
set
of
spans.
And
then
I
guess
we
can
actually
switch
over
to
the
attribute
section.
B
B
B
F
F
So
if
we
have
stuff
this
stable,
that
that
would
take
precedence
over
things
coming
in
from
ecs
and
they
would
work
on
doing
the
migration
on
their
side
from
what
I
understand
to
make
that
work,
but
then
going
forwards
after
the
merger.
It
would
just
be
one
one
group
working
on
semantic
conventions
going
forwards,
which
I
think
is.
F
To
have
them
on
board
as
well.
Their
stuff
is
more,
you
know,
event-based
right,
it's
like
logging
conventions,
but
it's
been
around
for
a
while.
So
maybe
one
action
item
is
for
people
in
this
group
to
take
a
look
there
and
see
what
they've
already
defined
for
for
messaging
systems
and
the
like
so
yeah
just
an
fyi.
F
Can
you
share
what
it
means?
Oh
I'm
so
sorry
yeah.
I
should
have
done
that.
So
ecs
is
elastic
common
schema,
so
this
is
elastic
and
elk
and
cabana
like
that
whole
logging
ecosystem
from
elastic
is
like
an
open
source
logging
ecosystem,
that's
been
around
for
a
while,
and
so
they've
done.
F
You
know
something
very
similar
where
they've
they've
defined
a
schema
for
all
the
common
events
that
can
happen
in
a
system
and
basically
like
attributes
like
our
semantic
conventions
and
it's
open
source,
but
you
know
kind
of
focused
around
elastic
the
company,
but
they're
trying,
I
think,
to
on
some
level
in
general,
migrate.
Their
their
client
and
telemetry
stack
over
to
open,
telemetry
or
at
least
be
compatible
with
it.
And
so
one
thing
they'd
like
to
do
is
is
basically
donate.
F
Ecs
to
open
telemetry,
so
we
don't
have
two
two
competing
semantic
conventions.
D
B
That
definitely
makes
sense
so
yeah
I've
been
looking,
I
think
it
attributes.
We
should
then
look
both
at
the
ecs
and
also
at
the
cloud
events,
let's
back
and
try
to
not
to
reinvent
the
wheel
and
see
what
we
can
kind
of
where
we
can
be.
F
F
B
C
D
So
next
week
is
going
to
be
settlement.
B
For
next
week,
let's
talk
about
settlement,
maybe
process
bans.
If
we
get
to
it,
I
think
for
settlement
we
kind
of
already
agreed
that
we
definitely
want
to
have
something
about
settlement
in
the
version
semantic
conventions.
B
D
C
F
So
see,
there's
also
a
chance
we
might
have
bogged
in
next
week.
Haven't
heard
back
from
him,
but
if
we
do
then
we'll
also
have
a
big
discussion
about
links.
B
B
Awesome
thanks
all
that
was
great
progress
today,
after
for
some
weeks,
dabbling
a
bit
in
the
dark
about
the
producer
instrumentation.
So
I'm
glad
there's,
finally,
something
we
can
write
down.