►
From YouTube: 2022-08-23 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
A
B
Okay,
let's
maybe
go
ahead,
so
I
was
on
pto
the
last
time.
I
know
you
guys
discussed
the
the
agent
versus
client
term
and
I
saw
you
or
not
where
you
think
that
it's
a
good
idea
to
use
client
instead
of
agent.
I
was
wondering
I
guess
so.
I
went
through
the
spec.
I
tried
to
see
what
it
would
look
like
if
we
just
do
the
search
and
replace
of
everything
agent
by
client
and
in
some
places
it
doesn't
really
make
sense.
B
So
I
don't
know
if
you,
if
you
had
a
chance
to
look
into
that,
do
you
think
we
could
just
stop
referring
to
the
agent
altogether
or
or
more
nuanced
approach
like
what
I
said
is
is
really
necessary.
Do
we
keep
the
references
to
the
agent
where
needed,
while
the
rest
becomes
a
client?
A
Well,
I
haven't
yet
looked
at
this
pull
request.
I
will
definitely
do
this
soon,
but
I
just
wanted
to
remind
you
guys
that
agent
is
even
in
the
name
of
the
protocol.
Opm
contains
agent
itself,
so
we
cannot
get
rid
of
it
completely.
B
A
B
Yeah,
but
by
the
way,
the
pr
that
I
placed
the
link
to
here
in
the
in
the
dock-
it's
not
a
replacement
of
of
the
agent
by
client.
It's
it's
just
a
small
clarification
which
tries
to
explain
what
is
the
relationship
between
agent
and
client
by
also
adding
what
the
possible
usage
of
a
supervisor
is
without
going
into
too
much
detail.
B
A
A
You
know
to
rename
to
client
capabilities
and
to
client
like
client
searching
for
server
message
and
server
to
client
message
at
that
point,
it
just
sounds
so
generic
that
you
know
you're
you're
almost
talking
about
any
client
and
server,
and
there
is
intention-
and
in
that
you
know
it's
a
management
server,
sending
a
message
to
manage
a
client,
and
so
I
think,
in
that
regard
the
use
of
agent
and
those
places
make
sense,
and
I
think
the
agent
capabilities,
whether
that
is
a
capability
of
the
client
implementation
itself
or
of
the
agent
that
it's
representing
you
know
it's.
A
It's
kind
of
clear
that
that
the
that
this
is
the
capability
of
the
agent
to
you,
know,
report
metrics
or
report
traces
and
things
like
that.
Not
yeah,
not
a
client
doing
that.
So
I
think
it's
it's
kind
of
hairy.
I
kind
of
like
I
like
your
general
statement
at
the
top,
which
I
think
clarifies
things
nicely
with
the
diagram
we
could
just.
A
B
Okay,
okay,
maybe
I
can
try
to
do
a
pass
and
see
where
actually
I
can
make
this
replacements
without
making
it
more
confusing.
I
I
do
agree
with
you
like
the
ability
to
report
metrics
or
to
accept
or
to
accept
configuration
or
to
report
an
effect.
If
you
have
an
effective
configuration
at
all,
is
the
agent
capability
right?
It's
not
the
client
capability,
it's
not
the
configuration
of
the
client,
it's
the
configuration
of
the
agent,
which
is
different
things
right.
The
client
itself
has
some
notion
of
configuration.
B
B
I
had
a
very
quick
look
so
anyway,
it
wasn't
very
simple,
but
I
can
try.
It
probably
will
touch
a
lot
of
places
like
I
think,
there's
literally
hundreds
of
references
of
the
word
agent
in
the
specification.
So
it's
going
to
be
quite
some
quite
some
pr
to
review
as
well,
not
just
to
make
the
change
anyway.
Let
me
try.
Let
me
try.
It
probably
also
means
inevitably,
some
of
the
proto
message
names
may
need
to
change,
not
sure
which
ones,
but
maybe
some.
B
B
Okay
cool,
so
I
I
saw
you
discussed
it
last
time,
there's
only
two
open
issues
remaining
for
1.0.
This
was
the.
This
is
one
of
the
issues.
The
second
one
is
is
essentially
testing
and
understanding
the
impact
of
the
the
frame
size
limits
which,
which
was
hinted
to
me
by
someone
else
who
had
experience
with
sockets
with
web
circuits
in
the
past.
B
I
don't
know
how
to
test
this,
to
be
honest,
because
the
the
web
sockets
library
we
use
does
not
from
what
I
can
see
does
not
provide
any
any
knobs
to
alter
the
frame
size
limits.
There.
A
B
Maybe
requires
some
sort
of
re-implementation
of
at
least
basics
in
using
some
other
web
sockets
library,
maybe
even
in
some
other
language,
no
idea,
but
I
guess
this
is
probably
important
to
confirm.
We
don't
want
to
end
up
in
a
situation
when
we
have
essentially
a
broken
protocol,
because
interoperability
is,
is
an
issue
depending
on
is.
B
It
probably
requires
diving
deeper
into
the
the
implementation
to
the
source
code
of
the
library
which
I
didn't
do,
because
I
had
just
a
cursory
look
into
this
issue.
If
you
guys,
maybe
can
help
with
this
one,
and
then
I
take
the
the
the
agent
to
client
renaming.
B
A
Okay,
well,
I
don't
know
anything
about
it
either.
I
think
that's
what
we
all
decided
on
the
last
call
that
nobody
knew
anything
about
it,
but
yeah.
B
B
A
B
A
Know
I'll
give
you
one
example
which
is
sort
of
a
a
snapshotting
capability
of
getting
some
recent
telemetry.
That's
been
sent
through
the
pipeline
and
we
want
that
for
the
purposes
of
configuration.
So
when
you're
creating
your
configuration,
you
can
see
some
of
the
telemetry.
A
So
this
is
not.
You
know,
as
as
you.
A
Business,
we
are
not
an
endpoint
or
a
destination
for
telemetry.
We
just
want
to
grab
some
so
that
we
can
help
you
configure,
and
you
know
we
already
have
this
connection
open
to
the
agent
and
it
seems
sometimes
reasonable
to
want
to
send
that
back.
We
are
instructing
the
agent
to
report
that
telemetry
via
configuration
and
it's
it's
a
little
bit
of,
I
think,
from
a
like
a
pure
perspective,
a
little
bit
of
a
misuse
of
configuration,
because
it's
a
very
it's
more
like
a
message.
A
You're
telling
it
to
please
report
some
telemetry
and
it
does
it.
But
it's
a
transient
thing,
not
a
permanent
configuration
change
and-
and
I
just
wonder
you
could
really
open
a
can
of
worms
with
like
a
open-ended
message
that
can
be
sent
along
with
it.
It
no
longer
becomes
a
protocol,
it
becomes
a
transport,
but
you
know
I
I
just
I'm
just
wondering
what
your
general
thoughts
are
and
yeah.
B
I
mean
that's
fair,
that's
fair
right,
I
mean,
if
you
have
a
large
fleet
of
agents.
It's
it's.
It's
a
concern
right.
You!
You
probably
want
to
have
a
limit
on
how
many
connections
you're
handling
on
on
your
server
side.
So
purely
I
guess
I
mean
if
you
try
to
approach
this
from
the
perspective
of
pure
separation
of
concerns.
You
probably
shouldn't
do
this
right
right,
but
if
you
approach
it
more
practically,
then
I
guess
you
have
to
compromise
on
this.
Probably
maybe
I
don't
know
so.
B
There
is
an
open
issue
about
this
actually
in
in
our
spec
repo.
Let
me
post
the
link
to
that.
It's
issue
number
49,
which
is
which
says
ad
ability
to
send
custom
messages.
It's
essentially
what
I
think
what
you
were
asking
for,
and
one
one
way
is
to
just
have
a
another
height
type
field
right
in
the
in
the
top
level
messages
that
we
have
which
allows
the
agent
to
send
anything
encode
it
in.
B
I
don't
know
I
mean
probably
if,
if
maybe
you
can
articulate
the
the
specific
use
case,
you
have
there
in
this
this
issue
and
if
we
can
come
up
with
a
couple,
real
world
reward
use
cases
that
justify
I'm
not
strongly
opposed
to
it.
We
definitely
shouldn't
block
the
release
because
of
this,
but
this
can
be
an
additive
change
right.
It
doesn't
have
to
happen
before
the
1.0.
B
It
can
be
a
new
capability
that
to
declare-
or
even
it
may
be
yeah.
It
probably
should
be
a
capability.
I
don't
know-
maybe
maybe
even
it's
not
a
capability
right
so
anyway,
I'm
not
strongly
opposed
to
it
like
for,
for
the
reasons
you
said.
Maybe
it
kind
of
probably
doesn't
belong
if
you
approach
it
like
with
complete,
pureness
of
design,
doesn't
belong
to
all
pump.
But
again
the
the
practical
side
of
me
says.
Then
okay,
am
I
supposed.
B
But
yeah
this
is
about
extensibility
without
requiring
that,
whatever
extension
is
being
coded
in
the
op-amp
specification
itself,
right
right,
what
level
of
extensibility
and
how
much
control
we
want
to
have
over
what
is
possible
here.
I
guess
that's
debatable
like.
Is
it
literally
a
series
of
bytes
that
you
don't
know
what
they
are
or
there
is
some
sort
of
structure
to
it
like?
Maybe
it's
a
list
of
key
value
pairs
that
is
a
bit
more,
I
guess,
looks
a
bit
more
controlled.
Although
yeah,
I
think
I.
A
B
Yeah,
okay,
yeah,
so
if
you
want
to
give
it
a
try,
I'm
I'm
happy
to
review
it.
I'm
I'm
fine!
I
think
I'm
again,
no,
no
strong
opinion
on
this
yet,
but
yeah
anyway.
There
are
a
couple
possible
options
here:
right
completely
raw
sequence
of
bytes,
what
you
described
like
a
type
and
and
the
value
maybe
or
just
maybe
a
bit
more
structured
list
of
key
value
pairs
or
something
like
that,
where
the
values
are
series
of
bytes
yeah.
B
A
A
B
B
So
I
would
say
maybe
think
about
this
alternates
that
we
discussed
and
maybe
there's
some
constant
pros
for
reach
and
make
a
proposal.
Let's,
let's
have
a
look
at
it.
A
A
So
it's
going
to
go
up
again
and
I
don't
want
it
to
be
abused
to
the
point
that
we
no
longer
you
know
can
talk
to
any
agent
or
you
know
do
that
we
have.
We
have
like.
We
don't
want
to
put
too
much
proprietary
mechanism
in
place
where
we
lose
our
compatibility,
but
but
we
you
know,
we
feel
strongly
that
you
know
compatibility
is
our
goal.
We
want
to
manage
lots
of
agents
and
and
yeah.
B
A
B
One
possibility
is
that
if
this
custom
message
allows
you
to
carry
let's
say
a
list
of
key
value
pairs,
then
maybe
we
introduce
sort
of
the
equivalent
of
semantic
conventions
that
we
have
in
open,
telemetry
right.
What
are
some
well-known
keys
that
we
can
use
there
to
represent
whatever
we
want
to
represent
there
like
it
becomes
sort
of
extensible
in
the
sense
that
you
can
use
your
custom
key?
B
If
you
don't
want
to
to
be
to
use
something
that
is
already
well
defined,
or
you
can
choose
from
a
list
of
this
things
that
we
do
know
they
are
part
of
the.
Essentially,
it
makes
the
op-um
spec
extensible
without
requiring
changes
to
the
proto
itself
right.
You
don't
need
to
change
the
product
anymore,
so
for
kind
of
for
the
cases
where
also
you
don't
maybe
care
about
the
payload
size
right,
there's
no
need
to
try
to
optimize
to
squeeze
the
smallest
amount
of
bytes
there.
B
A
I'm
traveling
the
rest
of
this
week
and
half
of
next
week,
so
I
don't
know
if
I'll
have
a
lot
to
report
in
two
weeks,
but
I
will
work
on
both
of
these
issues.
I
we'll
definitely
try
and
look
at
the
frame
size
thing
before
our
next
next
meeting
in
two
weeks.
B
A
B
Sounds
great,
okay,
anything
else
to
discuss
anyone.