►
From YouTube: 2023-03-16 meeting
Description
Instrumentation: Messaging
C
B
B
A
E
A
D
D
Well,
firstly,
this
Monday
in
the
scheduled
meeting.
It
was
again
just
trial
and
me,
so
we
also
canceled
I,
think
it
doesn't
make
sense
if
just
we
too
are
discussing
stuff,
so
I
think
we
can
take
off
this
Monday
meeting.
We
can
take
that
off
the
calendar
for
now
and
maybe
and
maybe
start
a
second
meeting
up
again
later,
when
you
are
kind
of
in
an
more
like
when
we
have
a
deadline
for
declaring
stability
but
I.
Think
for
now
we
weren't
able
to
do
that.
D
D
You
and
one
thing
I
did:
maybe
we
can
have
a
look
at
that
I
re-organized
our
message
board
a
bit
and
also
like
cleaned
up
some
issues
to
make
it
look
similar
to
the
HTTP.
D
Wait,
let
me
just
change
the
zoom
here,
okay,
so,
and
what
I
did
is
to
basic
clearly
not
have
asked
Port
where
PRS
and
issues
are
mixed,
but
just
having
this
back
clock
just
consisting
of
issues.
D
Basically,
assuming
that
we
have
an
issue
for
each
task
and
then
here
we
see
the
PRS
that
are
linked
to
those
issues
here
and
I
mean
that
should
give
us
some
kind
of
checklist.
For
for
what
we
need
for
V1,
that's
stable,
so
I
mean
maybe
we
can
take.
Maybe
five
or
ten
minutes
go
through
the
list
and
see
at
least
the
Vivan
list
and
see
whether
there's
anything
that
we
can
throw
out
or
if
there's
anything,
missing,.
D
I
mean
this
one
here
that
is
few,
that
I
took
as
the
issue
that
I
linked
to
the
pr
that
we
are
currently
discussing
the
semantic
conventions
we
are
because
yeah
it.
Basically,
it
describes
the
problem
that
there
is
that
the
that
the
examples
in
the
message
in
the
existing
semantic
conventions
are
ankier.
D
It's
not
clear
when
you
use
current
trials
when
to
use
links,
so
I
think
that
the
covers
pretty
well
what
we're
currently
working
here
in
the
span
structure
messaging
scenario,
then
this
is
something
those
are
the
two
issues
that
we
discussed
last
time
that
the
root
middle
is
working
on.
Here
we
have
this
PR,
it
is
opening
for
open
for
moving
destination
kind.
D
D
This
here
is
something
that
I
think
Miller
you
submitted,
and
this
was
about
having
foreign.
D
D
Okay,
then
I
will
probably
also
just
link
I
guess:
I
can
link
the
same
pull
request
to
two
issues,
so
we'll
then
link
this
pull
request
to
this
issue
here,
Yes.
A
B
The
way
I
think
you
could,
even
if
we
don't
close
the
issues
now,
I
think
it
could
be
great
if
we
can
just
send
put
sorry
put
the
link
there
to
the
tab
just
for
reference
in
case
some
people
come
and
say
you
know
what
I'm
interested
in
this
and
you
know
so.
They
know
that
there's
an
attempt
that
you
know
there's
priority
so
to
speak.
D
B
D
And
here
that's
the
next
one
I
think
that
will
be
relevant
for
us
because,
as
far
as
I
see
it
I've
also
decision
made
of
aligning
with
ECS,
so
I
think.
We
then
need
to
at
least
I'm
not
sure
how
much
changes
will
arise
from
that
per
messaging.
But
we
should
at
least
go
through
all
the
attributes
that
we
have
in
the
semantic
conventions
and
see
whether
there
is
a
something
in
in
ECS
in
the
elastic
common
schema
that
that
we
kind
of
conflict
with
net.
D
Or
the
attributes
we
use
from
the.net
namespace
I
think
those
will
be
impacted,
but
that's
some.
That's
that's
a
trunk
of
attributes
anyway,
that
we
share
with
http.
D
So
you
guys
think
that
needs
to
be
there
for
the
V1,
stable
semantics.
Then
this
here.
Yes,
that's
the
issue
for
the
span
or
allowing
links
after
span
creation
time.
There
is
those
two
open
PRS.
So,
let's
see
which
of
those
finally
makes
it
and
that's
kind
of
your
prerequisite
of
what
we're
working
here
in
the
Otep
here.
This
capture,
Kafka
cluster
ID,
I'm,
actually
tempted
to
move
this
out
of
the
version.
D
One
I
mean
it's
a
small
thing,
but
it
I
think
it's
not
something
that
we
really
need
to
do
for
stability.
We
can
add
attributes
later
on
easily,
so
I
was
actually
wondering
about
moving
that
moving
that
out
of
here
it
was
more
thing,
but
it's
just
something
that
you
would
save
us
at
least
some
time
when
you
don't
need
to
worry
about
that
and
work
on
PRS.
For
this.
E
Yeah
now
I
said
that
this
attribute
probably
would
land
in
a
in
a
separate
fire
right
for
the
Kafka
common
attributes.
I
guess
or
would
it
be
in
the
name
document
like.
D
We
don't
know
that
is
a
good
point.
That
is
actually
that
is
actually
an
item
that
is
missing
here
and
I
will
add
that
that
we
split
up
the
the
set,
the
current
semantic
convention
document,
and
then
we
have
like
one
document
for
generic
semantic
conventions
and
then
other
documents
for
the
system.
Specific.
E
D
D
So
that
is
moved
out
and
I
will
create
an
issue
for
splitting
up
the
the
semantic
conventions
in
generic
and
specific
ones.
B
The
way
by
the
way,
there
is
a
PR
creative
related
to
these.
We
don't
have
to
discuss
it
now
here,
but
it's
about
I,
don't
I,
don't
know
whether
it's
actually
the
same
I
think
it's
the
same
and
tigrant
was
asking
questions
around
that.
B
D
Then
we
have
this
here-
that
is
a
very
old
one
and
the
I
think
we
discussed
that
some
time
ago.
Of
basically,
the
thing
here
is
that
the
for
those
content
length
attributes
there
is
like
different,
very
different
namings
in
HTTP
to
your
PC
and
messaging
and
I.
Think
for
messaging.
We
even
have
the
underscore
bytes
here
for
triple
seats
underscore
size
for
HTTP.
It's
underscore
lengths
so
three
different
names
and
ask
queries
to
kind
of
unify
this,
and
they
make
a
proposal
here.
I
I'm,
not
sure.
A
We
did
and
I
was
going
to
submit
the
pull
request
and
then
the
UCS
story
started
and
actually
initially
as
they
have
something.
So
there
was
some
I,
don't
remember
what
we
decided
for
HTTP,
but
I
guess
here
we
can
just
go
to
ECS
and
find
attributes
there
and
see
if
they
like
them
or
what
are
the
problems
we
could
have
with
them
and
probably
just
aligned
with
ucsmos.
There
are
good
reasons
not
to.
B
Yeah
I
think
that,
by
the
way
on
that
story,
as
you
know,
there
have
been
some
discussions
and
we
don't
have
to
really
go
on
exactly
do
what
they
do.
You
know
if
there's
a
universal,
completely
reason
you
know
to
do
whatever
we
want
in
our
site
and
explain
why
it's
totally
fine.
B
D
C
D
I
will
I'm
not
sure
if
we
will
make
a
decision
here
now.
I
will
definitely
leave
this
issue
here
and
then
they
can
decide
either.
We
realign
on
based
on
ECS
or
based
on
something
else,
or
we
kind
of
just
remove
the
attributes
and
go
to
V2
I
mean
I.
Think
it's
nice
to
know
how
large
the
message
was
that
was
received
or
was
sent
and
yeah
I
agree
with
the
aim
of
this
issue.
It's
not
nice
to
have
like
three
different
conventions
for
in
three
different
areas.
E
D
Think
you
can
move
things
up
and
down
here
so,
but
I
think
there
is
no
like
a
higher
authority
setting
you
can
you
can
change
the
order,
your
and
basically
change
the
order
located
on
top
is
what
we're
currently
working
on.
E
D
It
can,
we
can
add
labors
and
I'm,
not
a
trip.
Somehow
we
can
add
labels
and
then
you
can.
Then
you
see
like
you
and
then
you
can
add
high
priority
or.
D
Okay,
here
we
have
this
to
ask
for
an
additional
example.
I
also
think
that
should
be
then
covered
by
what
we're
working
on
here
with
this
Otep,
and
then
when
this
is
incorporated
into
the
spec
I
expect.
We
have
an
example
covering
a
better
sense
scenario.
B
Okay,
great
to
know:
okay,
perfect,
yeah
I
was
curious
about
this,
because
I
was
checking
Johannes
hotel
and
then
I
saw
this
and
I
was
curious.
Okay,
thank
you.
So
much
I
will
check
that
out
of.
A
D
And
here
the
next
one
that
was
a
follow-up
on
discount
events
demanding
conventions
that
throughout
it,
so
once
we
have
our
I
think,
maybe
once
we
have
this
oh
tip
done
here.
It's
a
good
point
to
see
whether
what
is
in
the
cultiv
and
semantic
conventions
how
it
fits
together.
We
saw
the
messaging
stuff
so
that
we
are
consistent
here
for
people
who
use
both
Cloud
events
in
a
messaging
scenario,
which
is
pretty
common.
D
D
Here
this
is
an
interesting
one.
That
is
one
that
I
think
we
talked
a
lot
about.
We
do
is
Tyler
and
I
think
that
is
also
then
a
follow-up
that
we
see.
Okay.
How
does
this
fit
in
with
the
with
this
current
proposal
for
the
span
structure
that
we
are
that
we
are
coming
up
so
think
here
for
this
issue,
it
will
mostly
be
applying
then
our
proposal
to
this
use
case
and
then
verify
whether
that
makes
sense,
also
in
connection
with
the
function
as
a
service
and
the
RPC
semantic
conventions.
A
I
wonder
if
it
just
belongs
in
messaging,
or
it
belongs
to
the
general
semantic
conventions,
because
it's
just
the
question
of
layer
and
how
we
represent
different
spans
it
can.
We
can
have
the
same
conversation
about
database
and
it's
more
like
a
general
spec
question
rather
than
messaging
one.
It
definitely
blocks
the
stability,
but
it
it's
not
the
resolution.
This
is
not
necessarily
within
this
group.
It's
bigger.
D
Yes,
I
agree:
that's
why
I
think
it's
it's
a
bit
sad
that
Tyler
doesn't
join
anymore
because
I
know
he
was
working
in
the
functions
or
service
group
or
he
is
still
working
there
and
I
think
what
here
would
be
to
do
from
our
side
is
just
taking
this
example
and
the
taking
our
proposal
for
the
span
structure
for
messaging
and
then
and
then
imposing
it
on
this
example
and
then
basically
show
that
what
they
come
up
with
is
better
yeah.
B
If
this,
if
this
one
is
not
so
urgent,
I
can
take
on
that,
because
I
am
doing
a
review
of
what
they
are
doing
so
yeah
or
I
could
even
ask
Tyler
you
know
for
for
for
help,
but
that's
only
if
this
is
not
urgent
and
I.
Think
it's
not
urgent.
D
I
think
it's
not
that
burning
urgent
now,
but
it's
something
that
we
need
to
sort
out
before
we
can
be
stable.
B
Right
so,
okay,
so
in
that
case,
if
that's
something
that
can
I
could
start
working
on,
let's
say
in
the
next
week
then
I
could
take
on
this.
D
That
would
be
great,
because
I
think
we
would
need
some
kind
of
some
connection
to
the
other
work
group
who
works
on
the
functions
of
service
stuff
to
to
make
sure
that
what
we
come
up
kind
of
work,
source
and
connection
with
each
other.
Understand
that
if
you
kind
of
capture
that
pretty
well.
B
Yeah
that
makes
sense
in
that
case,
let's
assign
that
issue
to
me.
So
we
don't
forget.
I
will
change
that
to
Tyler
in
case
he
actually
can
help.
Thank
you.
D
Okay,
it's
yours!
Now
thanks
Carlos
sweet-
and
here
we
also
have
a
question
about
a
messaging
messaging
batch,
receive
scenario
and
assume
this
issue
will
also
beat
an
obsolete
once
we
have
our
span
structure
clarify
the
degree
on
here.
This
is
an
issue
that
I
think
Luke
Miller
you
brought
up,
I
I
didn't
have
I
saw
you
reviewed
the
pr
yesterday.
I
didn't
have
time
to
answer,
but
I
think
this
issue
covers
covers
what
you
brought
up.
Yep.
A
D
So
that
is
also
definitely
something
that
I
think
we
need
to
to
tackle
it.
I
can
I
can
take
a
I
can
take
a
look
at
that.
Actually.
D
So
this
is
this
one
and
here
I
think
that's
from
yes,
you
look
Miller,
and
here
we
are
talking
about
the
other
operations
that
messaging
systems
offer
that
are
not
covered
by
this
very,
like
high
level
stage
model
that
we
have
with
the
create
publish
receipts,
deliver
settle.
A
Yeah
and
I
think
it's
a
question
of
adding
just
one
sentence
to
the
spark
that
this
operations
follow
common
attributes,
but
not
any
specific.
Other
specific
semantics.
A
A
So
I
there
are
some
other
team
members
on
my
site
who
implements
semantic
conventions
and
they
come
up
with
all
these
interesting
questions
that
are
absolutely
an
obvious
to
me
and
I'm.
Creating
issues,
sometimes
when
I
see
that,
like
the
this
is
the
ex,
like
external
person,
view
on
the
semantic
conventions.
D
A
D
Okay,
so
both
stability-
we
have
those
issues
here
that
we
just
talked
about
window
aggregation
I,
think
that
we
said
from
the
very
beginning:
that's
not
a
V1
stability
topic,
that's
kind
of
an
advanced
one,
then
here
yeah
sampling
related.
D
We
also
push
this
out
of
rebound
any
kind
of
sampling
related
questions.
This
one
I
am
I,
am
not
sure,
maybe
talk.
Let's
talk
about
this
at
the
end,
the
metric
stuff
here
context
and
package,
propagation
I,
think
context
propagation.
We
actually
have
more
or
less
settled
package
propagation.
That
is
something
that
we
would
still
need
to
think
about
in
the
context
of
messaging,
but
I
think
it's
also
not
the
V1
stability
issue
and
deal
that
also
we
just
moved
over
and
the
metric
semantic
convention.
D
That's
an
interesting
one,
because
I'm
mean
also
eager
to
get
input
here
from
the
HTTP
side,
but
yeah
I'm,
I'm,
I,
see
pros
and
cons
of,
let's
say,
of
stable,
stabilizing
the
messaging
semantic
conventions,
trust
tracing
part
without
any
metrics
part
I
mean
the
pro
is
that
here
we
then
have
a
smaller
scope
and
it's
probably
easier
for
us
to
push
to
through
the
corners
that
there'll
be
declare
something
stable
and
we
don't
know
whether
we
can
come
up
with
something
consistent
from
Matrix,
too
okay,
so
here
I'm
a
bit
I'm
a
bit
On
The
Fringe,
and
a
wonder
about
wonder
about
your
input,
especially
you.
A
I
would
like
us
to
a
tourist,
create
messaging
semantic
conventions
for
metrics
before
we
declare
tracing
stable
and
once
we
do
this,
we
will
have
a
understanding
if
something
does
not
align
well,
one
thing
that
we
will
discover
that
there
is
no
generic
error
attribute
and
we
cannot
put
anything
into
metrics
saying
the
preparation
was
successful
or
not.
A
It's
not
necessarily
blocking
messaging
metrics,
but
they're
useless.
So
it's
an
addition,
but
we
cannot.
Without
this
thing
we
cannot
declare
metrics
stable,
because
we
cannot
add
attributes
later
on.
D
A
Yeah
some
metrics
they
affect
which
attributes
the
attribute
requirement
levels
so
like,
for
example,
net
per
name
should
be
required
because
it's
needed
for
metrics
right
and
that's
the
cardinality
of
attributes
so
without
at
least
having
a
clear
understanding
which
metrics
we're
going
to
expose.
So
we
cannot
stabilize
the
requirement
levels.
We
cannot
be
sure.
D
A
Yeah-
and
there
is
one
more
item
which
I
think
we
need
to
do
before
stability,
which
is
not
mentioned
here,
you
don't,
we
didn't
spec
out
subtle
operation
and
we
have
to
because,
for
example,
the
settlement.
There
are
different
settlement
types.
You
can
reject
message,
you
can
say:
okay,
it's
failed,
you
can
say
okay
that
letter.
Don't
ever
nobody
should
process
it.
It
should
go
to
a
special
queue
and
you
can
complete
it
and
without
this
information
it's
kind
of
useless.
D
Okay,
so
that's
basically
the
two
things
I
currently
have
that
are
not
on
the
board:
I
will
create
issues
for
those
the
settlement,
operations
or
attributes
and
splitting
up
the
generic
and
the
system,
specific
ones
and
I'm
just
wondering
if
there's
anything
else,
you
can
think
of
that.
We
are
missing,
particularly
for
we
want
for
stable
semantics
that
we
didn't
that
we
don't
have
here
yet.
E
Getting
links
now
I
think
we
did
at
some
point
too
many
links
and
and
costs,
and
things
like
that
I
think
pointed
out
that
it
would
be
a
a
nice
to
have
a
way
to
configure
or
just
to
say
something
about
this,
like
for
the
user,
to
configure
I,
don't
want
to
this
or
something
like
I.
Wonder
if
you
should
add
this
as
well
like
a
statement
that
instrumentations
can
offer
a
way
to
configure
to
disable
things
and
so
on.
D
I
think
if
we,
if
we
need
want
that
I,
think
that's
part
of
this
work
here
to
spend
relationships
and
that
should
be
in
the
old
tab,
so
I
think
it
doesn't
make
sense
to.
For
me
at
least
it
doesn't
make
sense
to
like
have
a
separate
issue
here.
I
think
we
should
clarify
that
in
the
old
temporary.
E
Sounds
good
okay,
yeah
and
I
was
I
was
looking
at
the
pr
that
for
metrics
and
thing
it's
quite
old,
but.
E
I
think
the
way
to
find
out
like,
for
example,.
E
Metrics
I,
don't
know
where
this
person
took
this
metrics
I
didn't
read
everything,
but
if
there
is
a
place
where
we
can,
for
example,
take
some
metrics
that
are
already
well
known
and
that
could
be
relatively
easy
to
to
to
add
the
metrics.
So
but
the
the
the
thing
with
the
attribute
that
told
me
to
say
that
that's
true,
if
we
don't
know
the
attribute,
is
always
going
to
be
there.
E
So
we
can't
add
to
the
metrics
but
I
think
yeah,
but
once
we
know
the
metrics
I
think
the
most
work
is
probably
finding
out
like
what
metrics.
We
want
to
record.
A
Yeah
it's
just
there
is
no,
there
is.
There
is
no
metrics
standard
or
any
common
thing.
I
discovered
that
there
are
some
patterns.
People
are
interested
in,
but
in
terms
of
names
attribute
names.
What's
on
them,
it's
the
Wild
West.
D
Yeah
I
think
that's
the
that's
the
list
for
now,
as
I
said,
not
sure
if
anything
can
come
up
with
anything
in
addition,
then
feel
free
to
write
an
issue
and
put
it
on
here
and
I.
Think
one
thing
that
we
can
then
do
as
a
next
step
is
that
we
are
more
or
less
pickup
issues
here
and
and
work.
Our
way
through
I
can
I
will
actually
hear
a
sign
myself
to
this
one
for
to
spend
relationships
because
I'm
more
or
less
working
on
that,
so
that
we
have
some
clarity.
D
E
Do
you
also
want
to
have,
for
example,
issues
to
at
least
implement,
for
example,
once
the
women's
day
or
tap?
Do
you
want
to
have
at
least
some
prototype
that
to
go
before
stabilization?
So
we
like
can
can
ensure
that
it
works
the
way
we
we
want
to
work
more.
D
E
D
E
Over
about
the
kind
thing
about
the
drop
in
the
kind
thing,
I
I
also
discussed
with
some
folks
here
and
nobody
seemed
opposed
to
it.
Both
oppose
dropping
the
the
the
kind
attribute
so
I
guess,
there's
really
no
I
mean
at
least
on
the
people
that
I
just
talked
to
that,
doesn't
think
that
there's
a
really
a
really
a
need
for
this.
For
this
attribute.
A
C
A
Been
around
for
a
while,
is
it
something
that
we
can
get
merged
yeah.
B
We
can
but
Dwayne
posted
something
in
a
slack
I,
don't
know
whether
you
saw
that
I
think
that
what
what
I
could
do
personally
is
that
I
emerge
this
PR,
the
One,
removing
the
attributes
and
just
create
a
new
issue
with
what
Dwayne
posted
or
we
can
discuss
that
when
he's
back
and
we
create
an
issue,
so
you
know
so
nobody
feels
like.
We
are
ignoring
the
feedback,
you
know
and
if
we
decide
to
bring
something
back
but
yeah
create
the
issue
and
merge
the
pr
that
would
be
my
suggestion.
A
Okay,
cool
I
can't
create
an
issue
inside
him
and
then
we
will
link
it
to
the
pull
request
and.
D
D
And
Dwayne's
command,
so
there
are
also
signed
this
one
here
to
me:
the
consumer,
client
group,
ID
and
yeah.
So
we
have
the
top
five
forms
assigned
models
to
people
in
our
group
and
if
anybody
else
has
bandwidth
to
pick
up
working
I
mean
here
should
assign
this
one
to
you.
Carlos.
Are
you
fine
with
that.
B
Yeah,
that's
that's
fine,
yeah
I
think
that
I
need
to
talk
to
Tyler
about
the
options
as
I
as
we
know
for
context
in
the
specification
seek
I
mentioned
to
Tyler.
That
there's
one
option
to
include
those.
You
know
there's
actually
three
alternatives
to
how
to
manage
this
forego
and
C
plus
plus
we
don't
break
them,
and
I
mentioned
that
none
of
the
solutions
for
those
languages
is
perfect,
so
they
will
have
to
choose
one
because
you
know
once
they
decide
which
one
we
will.
C
D
C
E
E
B
Yeah
I
think
there's
there's
one
possibility,
but
that
will
be
long
term
that
will
replace
all
links
with
events,
but
that
will
happen
at
once.
You
know,
and
one
of
the
things
is
that
we
haven't
studied
properly
or
documented,
even
the
links
modeling,
the
the
links
that
that
a
model,
but
that
that's
a
big
possibility,
but
it's
like
for
medium
term
I,
would
say.
D
My
impression
is
that
people
would
tend
to
the
events
model
if
they
would
Design
This
from
scratch.
If
there
wouldn't
be
any
kind
of
support
for
links
already
there
and
it's
designed
from
scratch.
I
think
the
events
model
is
the
more
compelling
one,
but
given
that
they
also,
it
already
is
kind
of
representation
or
a
link
in
the
API
and
also
in
the
data
model.
That's
not
an
event,
it
seems
to
me.
People
are
kind
of
don't
want
to
introduce
correct
yeah.
A
E
D
But
we
took
longer
on
this
board
than
expectable
I
think
we
have
it
in
a
clean
State.
Here
we
have
the
first
I
mean
wonton
and
the
next
sixth
one
assigned
two
members
of
the
group,
so
I
I
think
that's
a
that's
a
good
start
and
that's
your
reflecting
the
state
of
the
work
so
yeah
thanks
everybody
for
taking
all
the
issues
here
and
the
answer
that
if
you
have
any
bandwidth-
and
you
don't
know
what
to
do
just
pick
another
one
from
the
list
here.
D
Okay
with
that,
let's
have
a
look
at
the
span
structure,
PR.
E
D
Here
we
go
and
some
small
thing
I
did
that
we
talked
about
last
time
and
not
sure
if
it
makes
things
better,
but
maybe
in
those
examples
I
played
a
bit
with
with
the
colors
and
the
those
ephemeral
spans
or
not
all
like
this
grayed
out.
D
So
one
first
change,
I
did,
let's
see
where
the
data
actually
removed
the
ambience
band.
Here
we
had
some
discussion
and
I
parented
to
settle
directly
to
the
deliver.
D
So
basically
we
have
no
ambient
here,
because
that
is
the
scenario
for
auto
settlement
and
we
say
Okay
Auto
settlement.
Actually,
the
instrumentation
should
parent
The
Settle
to
the
labor
span.
So
we
get
rid
of
the
cut
rate
of
this
ambiguous
ambient
one
here
and
for
other
scenarios
where
we
had
ambient
or
process
bands.
I
just
made
them
very
grayed
out
and
hard
to
read.
So,
hopefully,
people
focus
more
on
the
on
the
green
stuff,
which
is
the
stuff
that
we
deal
with
in
this
conventions.
D
So
that
so
much
for
the
cosmetic
changes,
I
hope
that
makes
things
a
bit
keyword
but
yeah,
let's
see.
D
And
so,
let's
get
back
to
the
comments
below
gave
some
more
detailed
reviews.
I
didn't
have
time
to
to
go
through
it
in
detail,
but
maybe
let's,
let's
use
the
remaining
10
minutes.
We
have
now
here
yeah,
that's
a
change.
I
will
still
do
that.
I
committed
some
changes
yesterday
for
commands
and
resolved
them.
That
is
still
an
open
one.
I
will
work
on
that
here.
D
I
think
there
was
this.
The
links
for
basically
creating
links
for
saddle
spans
so
that
the
saddle
span
link
to
the
create
context.
D
D
And
here
this
question,
I
actually
think
this
is
hopefully
obsolete
by
By
changes.
I
recently
did
because
I
added
some
description
before
the
examples
and
the
kind
of
grayed
out
these
Ambience
bands,
but
what
what
I
might
need
to
add
is
maybe,
like
your
custom
words,
what
ambient
means
in
this
context
because
yeah
it's
it's
not
clear
to
people.
A
D
Then
I
will
resolve
it
for
now.
Okay,
maybe
if
it's
the
changes-
it's
maybe
absolute.
Maybe
not!
Then,
let's
go
through
the
comments
here.
The
new
comments
from
yesterday
from
nutmilla.
So
here
that
is
a
wording,
change
yeah.
A
So,
like
I
think
it's
it's
the
one
clarification
that
the
broker
can
do
settlement
and.
A
D
A
I
now
regret
I
added
this
clarification,
because
I
think
it's
applied
to
both
cases
where
it's
settlement
on
the
consumer
settlement
on
the
broker.
So
so
maybe
we
should
remove
the
auto
settlement.
Part
and
just
mention
that
there
is
like
the
fire
and
forget
could
be
the
case
or
broker
can
know
the
supplement.
D
D
And
here
yeah
we
talk
about
these
mechanisms
for
sdks
to
allow
attaching
context.
D
A
Yeah
so
I
think
that
the
statement
that,
if
that
SDK
needs
to
do
something
to
let
users
add
context,
it's
not
necessary.
D
Yeah,
so
basically
we
remove
like
this
burden
from
the
sdks,
but
because
here
it
sounds
that
sdks
need
to
provide
like
a
dedicated
mechanism.
A
D
A
D
I
think
I
I,
don't
I,
don't
have
a
strong
opinion
here
and
I
I
faintly.
Remember
some
discussions,
but
I
think
the
idea
here
was
that
you
have
one
sir.
Once
there
is
a
standardized
way
to
add
those
contexts
to
according
to
certain
protocols,
let's
say
amqp
or
mqtt,
then
maybe
it
might.
It
might
make
sense
that
sdks
take
care
of
this,
because
they
can
ensure
that
the
context
is
added
into
standardized
way,
whereas
compared
to
users
just
kind
of
fiddle
around
with
metadata
and
maybe
doing
it
wrong.
A
I
guess,
then
it's
not
the
requirement
or
suggestion
for
messaging
as
the
case
or
instrumentation
libraries.
It's
the
requirement
for
open
Telemetry
SDK
to
provide
a
propagator
right
or
two
and
either
way
it's
not
something
that
we
need
term
messaging
things.
E
A
E
Agree:
yeah
because
the
the
opportunity
is
the
case
they
will
not
do
anything
right.
The
the
instrumentation
Library
messaging
library
that
that
will
populate
the
context
in
the
message
and
then
that
Library
should
already
have
like
a
little
bit
of
such
that
they
already
have
the
and
functions
and
ways
to
access
the
metadata
input
there
and
then
the
library
knows
which
field
at
which
metadata
to
add
so
I
think
that's
that
should
be
fine.
So
I
agree
with
the
suggestion.
I
think.
D
Okay,
so
I
I
will
add
that
there's
a
comment
that
the
other
propagation-
let's
add
here,
should
not
be
insured
by
the
messaging
sdks
but
by
propagators,
but
from
the
from
the
this
auto
point
of
view.
Basically,
maybe
we
will
just
remove
this
sentence
or
not
yeah.
E
D
Yeah
we
just
removed
that
sentence
and
fine
I
will
commit
that
right
away.
C
A
D
A
It
sounds
a
bit
off
to
me
feel
free
to
completely
ignore
this
comment.
I
done,
I
have
no
opinion.
D
D
So
maybe
that
is
the
more
I
mean
I
from
the
options.
Also,
what
you
give
here
I
would
actually
go
more
with
interacting
here,
because
that's
the
process
I.
Think
of
adding
adding
the
context
to
some
kind
of
carrier.
That's
what
we
call
interact.
So
if
you're
fine
with
that,
then.
D
Yes,
I'm
I'm,
very
fine
with
removing
any
kind
of
complexity
here
from
the
spec.
So
but
I
think
you
have
a
you,
have
a
motivation
here.
Let's
see.
A
Yeah,
so
essentially
it's
all
in
user.
Hence
how
deliver
and
process
if
they
created
are
related,
and
there
is
nothing
we
can
enforce
and
essentially
there
is
nothing
we
can
enforce.
Yeah
I
think
your
examples
are
quite
enough
to
demonstrate
that
there
is
a
variety
of
possibilities.
D
Yes,
I'm
I'm,
honestly
in
favor
of
taking
out
additional
like
complexity
and
I'm
fine
with
committing
this
I.
Think
one
thing
when
we
say:
okay,
the
delivery
spend
like
is
the
process
when
I
think
one
thing
that
people
might
say
here
is
that
no,
when
you
are
when
you
are
delivering
delivering
a
patch,
that's
not
really
the
case,
because
you
might
have
several
process
Bands
then,
under
this
deliver
span
bond
for
each
message,
but
yeah
I
think
we
allowed
to
model
this,
and
we
don't
need
this
sentence
here.
A
D
Think
we're
still
fine
in
that
case.
So
if
I'm
I'm
happy
to
to
to
remove
this,
and
also
it's
one
less
reference
we
make
to
process
bands
which
I
think
is
good.
A
Carlos
is
asking:
if
we
have
a
product
about
this,
the
short
answer
is
yes,
we
actually
use
a
very
similar
approach
in
our
messaging
SD
case.
Instrumentation.
Oh
he's
not
here
anymore.
Okay,
on
that
next
thing,.
D
So
I
will
put
that
that
I
mean
we
will
anyway
like
write
an
issue
for
that
for
the
prototypes,
and
then
we
can
talk
about
that.
I
mean
it
would
be
awesome
if
the
Azure
SD
case
could
serve
as
a
prototype,
because
there
we
already
would
have
then
several
languages
too,
but.
D
D
D
D
C
A
D
We
need
to
stay
strong
the
same
way.
We
stayed
strong
when
Tyler
came
and
asked
for
your
teaching
reducing
parent
trial
to
relationships.
I
think
we
became
pretty
confident
I
think
we
can
be
pretty
confident
about
the
model
that
we
have
here
and
stay
strong.
Okay.
We
are
one
minute
over
time,
thanks
everybody
that
was
a
good
session.
I
think
we
also
kind
of
started
at
least
started
having
a
structured
roadmap
and.
E
The
board
looks
great,
the
the
backlog
looks
great
yeah
thanks
for
putting
organizing
it
looks
very
nice.