►
From YouTube: 2022-01-05 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
B
C
C
B
Yeah,
that's
true.
Actually
I
I
see
in
the
in
the
chat.
That's
unfortunately,
ted
got
covered.
Yes,.
B
So
looks
like
he
will
be
not
be
able
to
to
join
today,
but
yeah
I
was
thinking.
Maybe
we
can
just
have
a
brief
discussion
related
to
the
topic
that
we
had
like
one
month
ago
or
something
related
to
the
the
security
concerns
that
we
started
discussing.
B
Yeah,
so
if
you
don't
mind,
I
can
share
the
screen
and
I
have
a
brave
discussion
all
right,
so
it
should
be
number
two
probably.
B
All
right
so
yeah,
the
discussion
is
the
following,
so
yeah
we
we
do
have
this
topic
that
we
want
to
basically
the
first.
The
first
assumption
was
to
for
us
to
just
kind
of
call
out
the
attributes
which
might
may
contain
sensitive
information,
but
he
also
said
that
it
might
be
too
early
for
us
to
even
think
about
this
as
of
now
so
yeah.
I
just
wanted
to.
B
C
Yeah,
I
remember
we
discussed
it.
I
discussed
this
in
a
sig,
maybe
the
last
sig
before
I
went
on
holidays
but-
and
I
discussed
with
colby
as
well,
who
works
on
the
same
team
as
me,
and
we
just
thought
yeah.
You
could
add,
like
an
extra
field
into
this
mandy
convention
to
say
hey.
C
This
is
positive,
like
it
could
be
sensitive
data,
but
I'm
not
sure
what
like
and-
and
it
might
help
down
the
line,
but
also,
I
think,
it's
possible
that
it
might
not
help,
because
we
don't
know
what
the
solution
is
going
to
be
regarding
security
and
obviously
the
security
stuff
needs
to
be
fleshed
out.
A
lot
in
detail
and
just
getting
some
really
basic
thing
into
this
main
convention
is
that
we
don't
know
if
that's
definitely
going
to
be
part
of
the
end
solution.
C
So
I
feel
like
it
needs
a
little
bit
more
fleshing
out
the
security
stuff
and
I
think
it's
possibly
and
and
colby
agrees,
and
I
got.
I
got
some
agreement
in
the
last
sig
as
well
that
it's
possibly
that
possible
that
it's
better
just
to
put
into
v2
and-
and
we
can
really
flesh
it
out
for
that
or
not
not
necessarily
v2
but
any
other
later
version,
but
flesh
it
out
a
bit
further.
When
we
get
to
it.
B
Yeah,
that's
actually
sounds
reasonable,
but
when
I
actually
you
know
when
I
think
about
these
security
concerns
and
the
all
the
attributes
that
can
potentially
contain
it
or
anyway
like
or
what
whatever
solution
we
we
decide
to
come
up
with
to
you
know,
handle
this
problem.
It
still
seems
this
list
of
attributes
might
be
helpful,
like
no
matter
what
and
yeah.
I
also
post
posted
this
thing
here.
B
So
for
now
I
believe
some
some
people
use
this
open
symmetry
collector,
which
basically
kind
of
agents
running
in
the
same
code
or
something-
and
it's
actually
easy,
I
believe
or
relatively
easy
to
do.
Some
kind
of
you
know,
processing
using
open,
cylinder
collector
so
having
this
list,
or
if
people
have
this
list,
they
potentially
can.
At
least
you
know,
make
some
automation-
or
I
don't
know,
provide
some
configuration
to
open,
select
a
collector
to
just
sanitize
those
fields
so
yeah.
B
This
was
my
kind
of
my
thinking
about
this
and
another.
Another
kind
of
you
know,
thoughts
that
I
had
is
that
for
the
first
version,
security,
just
kind
of
should
be
somehow
addressed
right.
Just
because,
if
we
go,
if
we're
talking
about
stable
version,
security
concern
is
something
which
is
kind
of
really
really
important
one
right,
and
it
should
be
there
probably
from
the
very
beginning.
B
But,
as
you
said,
there
is
no
current,
you
know.
Currently
we
have.
We
have
no
like
a
specific
idea
how
we
want
to
handle
this
and
how
we
want
to
resolve
this
problem.
So
it's
it's.
It's
totally
unclear
so
yeah
for
me,
you
know
I'm
on
the
fence
actually,
but
should
it
should
we
keep
it
there
or
should
we
remove
it?
So
that's
why
I
just
you
know,
want
to
discuss
it
as
as
much
as
possible
with
just
you
know,
to
make
a
decision.
C
C
I
guess,
process
telemetry
differently
if
it
has
some
sensitive,
possibly
sensitive
attributes,
but
I
also
don't
really
see
how
that's
how
that
would
be
used
in
practice
like
in
the
current
I
mean
you
say
it
is
used
in
practice,
but
at
least
for
our
use
case,
I
feel
like
it
wouldn't
be
reliable
enough
to
make
any
like
concrete
decisions
of
like
how
to
handle
that
data,
because
it's
like
semantic
convention
says
it
could
be
sensitive,
but
we
don't
actually
know
if
it
is
sensitive
or
not.
You
know
so.
C
Not
address
it
for
v1.
If
people
really
needed
address,
as
you
say,
they
can
address
it
themselves,
because
you
can
obviously
just
easily
write
a
processor
in
the
collector,
but
if
yeah
and
then
we
can
really
think
about
how
to
tackle
security
and
it'll
be
a
big
task.
It's
not
it's
not
an
easy
task
whatsoever.
I
think
it
needs
a
lot
of
thought.
C
I
know
sean
has
an
otep
about
it
and
it's
yeah.
It's
probably
something
that
requires
its
own
vote
so
itself,
really
just
just
security
in
general,
yeah.
A
So
I
think
this
is
what
we
discussed
in
that
before
the
holidays
happen.
I
think
between.
A
James
was
that
me
personally,
I
think
if
there
are
any
security
concerns
rather
like
we
can
call
it
out
on
the
spec
as
like:
hey
we're
not
addressing
it
right
now
that
you
know
these
are
areas
maybe
we
thought
of,
but
in
like
just
as
we
you
two
just
were
talking
like
it
needs
more
discussion
or
whatnot,
so
in
the
interim
that
it's
out
of
scope
for
v1,
so
you'll
have
to
handle
it
for
yourself,
but
that
could
also
be
the
point
or
like
an
ingress
point.
When
people
read
the
spec
as
like.
A
Well,
we
need
your
help
to
help
flesh
this
out
in
terms
of
like
hey.
What
exactly
are
the
ways
that
we
want
to
handle
it
and
have
it
in
the
spec?
I
think
right
now
there
are
a
lot
of
unknowns
and
even
to
put
something
very
basic
up
front.
I
kind
of
agree
that
it
could
be
something
that
can
be
prohibitive
with
us
making
advanced
advancements
in
v2
right
like
if
it's
not
something
that
we
actually
want
to
continue
doing
or
whatnot.
A
It
could
be
a
breaking
change
and
I
get
that
we
already
have
that
v1
to
v2
could
be
breaking
change
and
that
would
be
okay,
but
still,
I
think
that
we
want
to
try
to
minimize
that
if
it's
not
necessary.
So
if
we
don't
have
consensus
that
there's
some
even
basic
level
of
security,
you
know
specifications
that
we
want
to
introduce.
A
A
To
help
drive
it
in
v2
to
get
closure,
then
please
join
the
sig
or
you
know
that's
kind
of
my
thinking
that
I
think
that
we
can
make
handle
it.
I
don't
know
what
you
two
think,
but
I
think
that
would
be
great.
B
B
Like
a
really
good
reason
for
us
to
keep
it
in
scope,
for
we
want
definitely
yeah
yeah,
maybe
it
will
be
our
just.
You
know
we
try
to
try
to
do
best
our
best
afford,
but
for
now
we
don't
see
how
exactly
the
things
can
be
addressed
so
probably
yeah.
We
okay,
so
no
worries.
I
I
can.
I
can
do
that.
I
can
update
the
old
tap,
just
move
it
out
and
basically
we
can
address
this
going
forward.
C
C
Be
that'd
be
awesome,
thanks
dennis
so,
and
I
think
it's
it's
kind
of
a
win
as
well
right
because,
like
we
can
get
it
to
stable,
quicker
there's
one
less
thing
to
worry
about.
We
can
get
v1
there.
B
That's
true,
that's
true.
That's
also
like
a
one
of
the
reason
why
probably
I
just
wanted
to
you
know,
make
some
decisions,
no
matter
which
one,
but
you
know
but
yeah.
So
basically
we
just
discussed
this
one.
So
I
will.
I
will
move
it
and
just
put
some
some
note
here
in
terms
of
like
a
something
that's
we
want
to
address
going
forward
and
it's
really
important,
but
we
definitely
need
some
help
so,
but
just
just
wanted
to.
B
You
know
reiterate
once
again
what
we
have
here
and
what
is
the
current
state
and
what
our
like,
what
will
be
the
next
steps
here
in
terms
of
bringing
http
conventions
to
the
first
stable
version?
So
we
do
have
these
retries
and
redirects
and
context
propagation
thing,
and
I
do
have
a
couple
of
open:
pull
requests,
pull
requests.
Actually
the
first
one
is
to
to
the
specification
itself
like
I
a
document
itself
and
basically
what
it
brings.
B
It
just
adds
in
one
more
paragraph
or
like
a
couple
of
statements
here
in
terms
of
how
this
read
rise
and
redirect
spans
should
be
constructed
or
like
how
how
we
should
structure
them
and
for
context
propagation.
It's
also
really
close
here,
just
because
you
know,
as
as
as
the
approach
actually
to
you
know,
share
data
between
reprice
and
redirects.
B
That
is
basically
something
that
should
be
addressed
as
well,
and
I
another
thing
I
do
have
implementation
for
net
libraries,
for
the
instrumentation
library
for
http
and
basically
that's
instrumentation-
covers
like
a
different
cases
that
we
have
in
dotnet.
So
it's
really
legacy
implementation
and
the
current
implementation.
So
I
was
able
to
cover
both-
and
this
is
exactly
the
implementation
of
this
proposal.
B
So
what
I
was
thinking,
maybe
to
make
it
more
kind
of
visible
and
more
local.
Maybe
we
can
find
some
another
people
to
you
know.
Do
this
implementation
in
some
other
technology
stack,
like
I
don't
know
python
ruby,
whatnot
just
to
see
if,
if
it's
visible
there
and
how
it
will
work
there,
so
we
can
just
you
know,
make
it
possible
to
close
this
as
well.
So
what
is
the
retry?
B
Do
you
know
how
it
works
in
java?
Actually,
yes,
we
do
have
also
like
we
work
with
mila
several
weeks
ago
and
mill
was
able
to
so.
Let
me
try
to
find
it.
It
should
be
somewhere
here,
yeah
exactly
so
here
it
is,
and
this
is
the
implementation
of
the
same
stuff
for
for
for
java.
This
is
a
prototype,
but
basically
this
prototype
proves
the
visibility
of
the
of
the
approach.
That's
that
I
also
used
in
before
for
that,
but.
B
Right
so
the
first
thing
here
is
that
so
like
we
want
to
like
a
structure,
retries
and
redirects
in
a
way
that
for
each
like
a
physical
try,
we
need
to
create,
or
actually
that
says
must
we
need
to.
We
must
create
a
spam.
B
This
is
the
first
part,
so
for
each
physical
interaction
spawn
must
be
created.
Another
thing
is
that
those
spans
needs
to
be
linked
between
each
other.
Yes,
the
next.
The
next
street
drive
basically
should
be
linked
to
the
previous
one.
B
So
this
is
like
a
second
part,
and
the
third
part
here
is
that
this
retry
count
attributes
should
be
just
added
to
each
subsequent
retry
right.
So,
for
example,
for
the
first
try
it
will
be
just
like
a
first
try,
but
in
case
we
do
have
we
experience
some
retries.
B
We
start
adding
these
attributes,
so
it's
only
applicable
for
retries,
so
for
definitely
for
redirects.
There
is
no
such
such
thing
as
count,
but
still
for
redirects
the
same
structure
can
be
or
should
be
should
be,
should
be
done.
So,
basically,
we
need
to
create
a
spam
for
each
for
each
redirect
and
those
redirects
this
those
spans
should
be
linked
between
each
other.
C
Yeah,
I
agree
that
I
agree
with
most
of
what's
there
like
the
linking
of
the
spans.
I
assume
I
assume,
like
there's
a
attempt
at
http
requested,
fails
and
then
there's
a
retry
that
has
the
original
request
as
a
parent
span.
Is
that
how
it
works?.
A
C
A
The
way
the
links
work
is
like
when
you
integrate
that
so
normally,
when
you
just
are
stitching
spans
together
under
a
single
trace.
If
you
have
a
bunch
of
retries
like
if
it's
all
under
one
trace
id,
you
can
have
a
whole
bunch
of
them.
I
think
the
way
the
span
links
would
come
into
play
with,
that
is
that
it
actually
generates
a
new
trace
id,
but
it's
still
linked
back
to
that
original
trace
id,
and
so
I
know
different
people
have
introduced
that
and
work
use
that
we
have
that
as
well.
A
But
in
the
retry
scenario
it
works
really
well
in
the
fact
that,
like
if
you
let's
say
have
like
a
100
retries,
you
don't
necessarily
want
that
all
underneath
the
original
trace
id,
especially
if
they're
going
to
be
different,
they
could
be
like
you
know,
asynchronous
requests
or
whatnot
queuing
whatever
it
might
be.
So
in
that
case,
doing
spam
links
may
be
better.
B
That's
true,
yeah
and
another
reason
that
that,
like
those
traces,
can
be
constructed
differently,
as
michael
pointed
out
that
we
can,
we
can
have,
like
a
you,
know,
top-level
top-level
span,
basically,
which
represent
like
a
trace
creation,
and
in
this
case
all
everything
that
we
have
under
this
will
be
basically
represented
as
kind
of
like
a
spans
under
under
this
spam,
because
we
do
have
parent,
but
in
case
there
is
no
parent,
which
also
can
can
happen.
B
Capital
can
happen
in
many
different
cases.
In
this
case,
those
all
all
these
retries
will
be
different
traces
and
the
only
way
to
you
know
to
to
represent
them
as
a
kind
of
chain
of
retries
is
basically
to
link
them.
So
in
case,
in
this
case,
it
will
be
totally
different.
Traces,
but
spans
will
should
will
all
will
still
be
linked.
So
we
can,
you
know,
re
reconstruct
this
chain
on
the
server
side.
Definitely.
C
B
Yeah,
so,
basically
link
so
when
we're
talking
about
like
this
parent-child
relationship,
there's
basically
just
you
know,
corner
case
of
link
right.
So
this
this
this
we
have.
This,
that's
can
be
represented
as
linked
to
the
parents
and
link
is
just
you
know,
kind
of
ordered
stuff.
So,
like
a
directional,
so
we
can.
We
can
only
have
a
link
from
one
span
to
another
and
that's
that's
kind
of
represented,
really
really
simple,
linked
list
and
retry
account
here.
B
We
just
added
it
as
a
kind
of
you
know
next
step
in
this
direction,
so
having
just
retro
account,
we
don't
need
to
call
it
kind
of
you
know
on
on
a
platform
side
on
the
server
side,
we
don't
need
to
kind
of
calculate
or
count
all
this
re
all
these
links.
So
we
don't
need
to.
B
You
know,
go
through
this
list
and
we
can
just
take
the
kind
of
latest
the
the
last
the
last
try
and
see
how
many,
how
many
retries
happen
so,
basically
that
that's
the
only
reason
why
we
can
way.
We
need
to
put
it
basically,
this
kind
of
optimization
for
for
different
scenarios
that
can
be
implemented
on
the
server
side
in
terms
of
kind
of
analytics.
What
happens.
C
Yeah,
that
makes
sense.
I
I
have
some
doubts
over
the
retry
count,
but
I
I
haven't
looked
at
it
like
the
retry
account
attribute
because,
like
something
that
something
that
kind
of
seems
off
to
it
about
me,
but
but
I
think
it's
fine
for
now
yeah
that
sounds
good
to
me.
Did
you
need
more
people
to
kind
of
review
this,
or
what
did
you
need.
B
Yeah
yeah,
it
would
be
good
you
know,
to
to
to
to
bring
more
attention
to
these
pull
requests.
So
basically
it's
linked
under
under
the
the
the
under
the
oh
tap
and
yeah.
That's
basically
can
be
the
the
first
kind
of
ask
and
the
second
ask
if
it's
possible
to
also
spend
some
time
and
implement
it
using
different
technology
stacks.
So
we
don't
have
iodine.net,
but
it
might
be
also
beneficial
if
we
do
have
the
same
implementation,
but
for
for
some
other
language
it
also
can
help
for
this
particular
topic.
C
B
Yeah,
but
at
least
you
can
also
verify
or
got
the
like.
I
get
the
overall
idea
from.
Let
me
let's
pull
requests
as
well.
C
Yeah:
okay:
let's
take
a
first.
B
Yeah,
so
that
was
one
thing
that
I
wanted
to.
You
know
call
out
here,
and
another
thing
is
that
we
do
have
so
if
we
go
security
concerns
out
of
scope,
if
we
move
it
out
of
scope,
we
still
have
a
couple
of
things
in
scope,
apart
from
representation
context
propagation.
So
we
do
have
these
error
status
defaults
and
it
should
be
really
really
simple.
So
we
already
have
this
kind
of
behavior
for
server
side
spans.
B
We
don't,
we
don't
put
any
any
status,
but
it's
not
really
consistent
with
a
client
side
span.
So
basically,
that's
that's
something
that
we
should.
We
can
make
and
make
it
more
straightforward,
and
this
this
one
should
be
really
simple
another
that.
C
B
B
But
it's
just
like
an
indication
that
object
is
still
is
not
kind
of
active
or
not
not
really
created
during
this
particular
moment
and
the
same,
the
same
can
be
can
be
said
for,
for
example,
two
of
like
four
four
to
nine.
So
like
a
if
server
is
busy
and
cannot
accept
some
requests,
it
will
be
like
a
49
and
client
also
just
need
to
basically
retry
right.
B
So
from
this
perspective,
it's
in
some
cases
and
that
not
gonna
really
really
depend
on
a
client,
and
we
do
have
this.
This
behavior
for
server,
and
probably
it
will
be
good
to
to
you-
know,
unify
it
from
the
from
the
clients
and
perspective
as
well.
So
it
will
just
consistent.
C
Yeah,
like
I
can
see
that
it
seems
like
it's
a
more
of
an
edge
case
for
client,
but
if,
if
we
need
to
be
able
to
take
in
that
edge
case,
then
I
guess
that's
fine
yeah
yeah.
B
So
yeah,
basically,
that's
also
the
just
a
really
first
step
in
this
direction
because
for
kind
of
v-next
we
do
have
this
this
action
item-
or
this
topic
mentioned
here-
that
it
can
be
or
yeah.
I
was
saying
401,
but
it
should
be
404,
sorry
about
it,
but
yeah
going
forward.
We
might
want
to
introduce
some
kind
of
configuration
language
which
allow
clients
like
a
configure.
B
How
different
status
code
can
should
be
treated
on
the
client
side.
Should
it
be
its
error,
or
should
it
be
no
error,
kind
of
or
unset
status,
so
but
yeah.
B
Right
so
yeah
for
one
it's
it's
security
stuff
is
identification
yeah.
My
my
bad
out,
I
was,
I
was
wrong.
Yeah.
B
Yeah
or
409,
which
is
the
conflict
right,
so
all
this
stuff
is
really
really
specific
to
the
api
which
client
talks
to
and
yeah
so
yeah.
Definitely
it's
like.
I
should
be
somehow
configured
on
the
client
side,
but
like
what
is
the
configuration
kind
of
mechanism
we
can
use?
There
is
also
something
that
needs
to
be.
You
know
needs
to
be
investigated
first.
B
Yeah,
and
so
basically
this
this
one
can
be
done,
and
I
would
you
know
it
will
be
great
if
we
can
find
some
if
you
can
have
some
volunteers
to
cover
it.
So
we
can
move
specification
to
the
to
the
version.
B
First
version
stay
faster
and
another
topic
that
also
we
have
here
is
like
our
attribute
sets
like
which
one
should
be
should
be
kind
of
considered
required,
and
it
looks
like
we
do
have
a
consensus
that
from
the
client
side,
the
only
thing
we
can
do
is
to
use
or
actually
say
that
http.url
is
the
only
only
one
required,
because
there
is
no
now
other
attributes
or
there's
no
scheme
called
a
target
and
the
only
http
url
is
something
exists
on
the
client
side.
B
But
from
the
other
hand,
on
the
server
side
there
is
no
url,
but
instead
we
do
have
scheme
hosts
and
targets,
or
we
do
have
this
this
four
or
these
four,
and
for
now
it's
not
really
clear,
like
a
for
the
for
the
for
the
user
or
for
customers
who
want
to
instrument
some
library,
it's
not
really
clear
which
exact
set
should
be
should
be
set.
It
should
be
used.
C
B
That's
true,
that's
true
yeah.
So
but
at
least
we
can
say
that
if
those
are
available,
this
is
the
default,
and
this
is
the
required
right.
C
B
B
Yeah,
so
basically,
that's
that's
what
it
is
so
like
at
least
one
of
the
following
is
required.
B
Right,
the
problem:
the
problem
is
here,
probably
that
we
don't
have
like
a
really
clear,
clear
statement,
which
is
the
required
right.
So
we
can.
We
can
probably
make
an
improvement
here
just
to
explicitly
cloud
that
this
is
the
required,
for
example,
and
in
case
host
does
not
exist.
Then
you
need
to
use
kind
of
you
know
server
name
or
if
server's
name,
the
server
name
does
not
exist.
You
need
to
use
this.
This
host
dot
name.
C
B
And
they
say
the
same
is
for
the
same,
the
same
for
port
right.
So
if
hosts,
if
host
is
there,
so
there
is
no
port
should
be
used.
But
if
part
is
like
a
host
is
not
there,
then
we
need
to
use
this
and
this
right.
So
that's
basically
will
will
improve
the
overall
kind
of
experience
just
just
because
it
will
be
really
clear.
What
exactly
should
be
done.
B
Yes,
yes,
so
the
first
thing
here
is
that
we
don't
probably
need
to
decouple
these
attribute
sets
for
client
and
server,
saying
that
for
clients
we
this
one,
is
required
and
that's
it
right.
So
this
one
is
required
period,
but
for
server
sides.
Basically,
we
just
it
probably
needs
to
be
just
clarified,
so
we
can
just
say:
okay,
this
is
the
attribute
set
and
yeah
in
case
something
isn't
available,
just
go
to
the
to
this,
and
this
consider
required
right.
B
So
basically
that
will
be
the
really
clear
guidance
and
really
clear
expectations.
Maybe
just
rephrasing
helps.
B
Yeah,
basically,
that
that's
the
that's
the
that's
the
point
that
we
have
here
so
yeah,
at
least
I
think
it
can.
It
can
help
here
like
I
just
to
understand
so
at
least
this
kind
of
queries
can
be
can
be
executed
easily.
B
B
So
yeah
is.
B
Nope,
that's
it
that
that's
it.
So
we
do
have
context
propagation
as
a
separate
one,
but
it's
really
kind
of
clear
or
really
related
to
the
to
the
read
rise
and
redirects,
because,
basically
for
the
retries
and
redirects
implementation,
we
are
using
this
kind
of
or
we
are
explicitly
pointing
out
how
the
how
data
should
be
reused
between
different
instances
of
http
client
requests.
B
Basically,
we
are
station
station,
the
data
that
needs
to
be
used
across
across
retries
or
and
it
can
be
depending
on
the
implementation.
It
can
be
something
that
exists
in
platform,
so
in
the
internet.
We
do
have
this
request,
that's
properties,
kind
of
dictionary
that
can
be
used,
but
if
it's
not
available,
it
can
be
some
some
kind
of
ambient
context
that
also
available
in
different
forms
in
them.
In
many
different
languages,
it
can
be
kind
of,
you
know,
threat
local
storage
or
it
can
be
just
another
implementation
of
the
same.
B
But
that's
that's.
Basically,
that's
basically
about
it.
C
B
Well,
that's
the
that's
the
intention
and
we
do
have
two
red
check
marks
here
and
I'm
trying
to
also
work
with
another
people
like
yuri
and
josh
to
make
more
approvals.
So
last
time
we
spoke
with
josh
or
sorry
with
yuri.
Here,
that's
like
a
yuri
just
asked
to
rephrase
some
things
saying
that,
like
it
said,
otap
shouldn't
provide
or
shouldn't
bring
some
idea
how
it
should
be
implemented.
Just
you
know,
it
needs
to
be
stated
as
a
yeah.
B
Yeah
and
last
time
on
november,
like
I
just
rephrased
several
sentences
but
yeah
looks
like
yuri
yuri,
wasn't
able
to
to
have
one
one
more
iteration
of
reviewing
so
yeah.
That's
that's
they'll,
be
probably
another
ask,
but
I'm
not
really
sure
who
I
need
to
address
this
house
like
how
to
bring
these
other
more
attention,
so
it
can
be
finally
closed
or
finally
merged.
Yeah.
C
I
think
it's
close
anyway
so
happy
to
work
on
the
on
some
of
these
things.
I've
written
down
a
few
things,
so
you
wanted.
C
C
B
Exactly
yeah
and
that's
what
I'm
trying
to
put
to
the
document
that
we
have
here
so
just
to
you
know,
make
it
here
more
implemented.
C
Oh
yeah,
I
can
put,
I
can
put
what
I
what
I
wrote
down.
B
Yeah
so
another
implementation
and
java-
let
me
put
it
here
so
I'm
going
to
like
the
dotnet
faults
are
basically
like
a
folks
from
microsoft.
So
I'm
going
to
we're
going
to
have
another
conversation
tomorrow,
and
this
will
be
the
one
of
the
topics
that
we
will.
B
You
know
discuss
there,
but
it
was
a
like
a
initial
discussion
with
uh.net
folks
from
open
telemetry
team
in
december,
and
basically
it
was
just
like
a
draft
draft
pull
request,
but
we
agreed
just
it
can
be
just
submitted
and
community
will
will
will
take
it
from
there.
So
I
expect
this.
This
will
be.
Will
will
take
more
like
a
will.
We'll
have
more
attention
this
week.
C
C
Sorry
come
again,
and
just
do
we
have
like
the
agreement
on
how
to
address
retries
and
redirects.
Yes.
Is
that
something
that
is
generally
kind
of
agreed
on,
like
the
way
that
you
spoke
about.
B
Oh
well,
yeah.
So
basically,
that's
that's
the
pull
request
about
this.
So
this
actually
answers
the
question,
so
I'm
trying
to
find
it.
Let's
answer
the
questions,
how
the
how
those
should
be
constructed.
C
B
A
B
That's
true,
that's
true!
So,
like
just
let
me
to
reiterate
it,
so
we
had
like
a
really
well.
We
had
several
discussions
about
how
it
can
be
implemented
during
november
and
october.
B
Probably
in
this
in
this
meeting
during
these
meetings
and
a
lot
of
different
things,
all
different
approaches
were
reviewed
that
just
you
know,
just
preliminate
kind
of
thoughts,
and
we
just
agreed
that
this
one
can
be
used
as
a
like
a
pass
for
the
you
know
for
for
the
for
a
thing
that
we
can
go
with
and
yeah.
B
Basically,
the
overall
agreement
is
here.
We
just
need
to.
You
know,
work
more
on
the
this
country.
This
specific
pull
request
just
to
also
make
it
more
kind
of
visible
and
eventually
make
it
make
it
merged.
C
Yeah,
okay,
cool
I'll,
definitely
try
and
help
out
with
some
of
these
points,
even
if
it's
just
some
pr
reviews,
maybe
I
can
put
in
a
spec
pr
to
address
some
of
those
concerns
like
the
error,
consistency
and
yeah,
I'm
happy
to
hopefully
do
that.
C
B
B
All
right
so
yeah
looks
like
we
do
have
all
the
action
items
here
so
yeah
require
already
bid
sets.
Okay,
so
yeah
looks
like
it
is
so
yeah
it
was.
C
Yeah
great,
I
don't
have
anything
else
to
really
bring
up.
I
just
expected
to
talk
about
this,
so
if
anyone
else
says
anything
then
feel
free.