►
From YouTube: 2022-09-16 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
C
Okay,
my
my
cat's
trying
to
give
me
attention.
So
if
I
just
randomly
disconnect
it's
because
she
unplugged
me,
apologies.
B
All
right,
maybe
we
should
go
ahead
and
get
started,
and
I
think
I
have
a
heart
stop
at
8
30.,
I'm
not
sure
if
we'll
get
through
all
these
or
certainly
continue
without
me,
but
one
of
the
things
we
said
before
is
that
in
terms
of
items
that
have
been
rejected
in
previous
weeks
in
particular
over
the
last
week,
we
let
big
for
a
week
and
then
recheck
them
beginning
of
this
meeting
and
enclose
them
as
appropriate,
as
opposed
to
just
leaving
them
and
definitely
open.
B
So
let's
take
a
look
at
2773,
which
is
the
one
from
last
week.
A
A
So
it's
it's
it's
okay
right!
We
can
keep
it
open
for
a
bit
more
okay,
just
in
case
there
is
more
evidence
for
the
need
for
this.
I
don't
think
there
is,
but
I
want
to
make
sure
that
we
still
give
the
full
opportunity
for
people
to
completely
express
their
opinion
right.
I
don't
want
to
shut
the
discussion
there.
A
Yeah,
I
think
this
is
this
is
a
valid
concern.
There
there's
a
known
issue
there
that
we
have
problems
there
with
the
truncation
and
the
invalid
characters,
the
attribute
names
or
the
values.
I
don't
remember,
which
one
was
that,
so
I
think
this
should
be
accepted.
B
C
C
A
B
A
I
mean
yeah
sure
it's
valuable,
I
don't
know
who
does
this,
though.
C
A
Maybe,
let's
let's
accept
it
and
say
that
we're
looking
for
someone
to
take
care
of
it,
I
think
that's.
Do
we
have
a
label
for
marking
that
we're
in
search
of
an
assignee
or
we
didn't
or
is
it
just
purely
if
it's
unassigned.
B
C
And
I
know
that
because
I
was
reading
a
different
bug
where
I
saw
that
yuri
was
going
to
open
these
three
yeah
yeah.
B
B
A
A
B
A
C
C
C
It's
like,
if
I
wanted
to
do
monetary
values,
I
would
use
decimal
because
it's
going
to
try
to
preserve
the
actual
decimal
as
a
separate
thing.
It
doesn't
have
the
same
restrictions
as
floating
point
numbers
right,
but
this
is
just
a
weird
request,
because
when
you
hit
otop
we'd
convert
it
to
double
or
integer
anyway,
so
we
don't
have
a
decimal
type
in
hotel.
C
So
like
any,
for
any
reason
why
you
would
want
this,
I
think,
would
just
we
should
just
say,
convert
from
decimal
to
float
sorry,
but
that
should
also
not
be
in
this.
It
shouldn't
be
in
any
way
they
should
go
to
the
language
sig,
because
it
could
be
that
maybe
the
language
sig
decides
to
support
decimal
and
do
that
conversion
for
you
but
yeah.
I
would
say
please
open
this
with
the
language
that
you're
having
trouble
with.
B
C
Yep
yeah
yeah
I'd
also
say
that
I
don't
think
we're
going
to
support
a
decimal
type
and
histogram
in
the
spec,
if
that's
what
they
ask
just
as
an
fyi.
So
if
you
see
a
follow-up
here,
okay
yeah,
like
we
don't
plan
to
support
decimal
in
otlp,
so.
C
B
B
A
C
This
is
this
goes
back
to
whether
our
specification
is
documentation
for
how
open
telemetry
works
or
a
specification
for
how
to
implement
like
exactly
the
the
requirements
we
and
we
have
both
in
our
spec
yeah
right.
So
I
would,
I
would
say
yes,
I
think
this
belongs
in
the
hey.
What
does
our
spec
look
like
aspect,
but
it
shouldn't
be
in
the
like
here's
exactly
what
you
need
to
be
otp
compliant
part.
It
could
be
in
one
of
those
like
addendum
things.
A
So
the
reason
I
think
it's
it's
a
valid
request
is:
if
you
look
at
the
rfcs
of
different
protocols,
they
very
often
show
examples
right,
yeah,
the
rfs
are
very
precise
about
what
the
protocol
is
about,
but
they
also
include
some
examples
and
the
reason
is
because
it
makes
it
easier
to
understand
the
specification
right
when
you,
when
you
see
an
exact,
precise,
payload
yeah.
So
for
that
reason
I
think
it's
a
valid
request.
A
The
reason
I'm
reluctant
is
because
otlp
binary
is
our
encoding
choice,
default
choice
and
there's
no
good
way
to
to
show
it
really
in
that
document.
If
we
show
all
tlp
json,
I'm
worried
that
it
may
create
an
impression
that
somehow
we
endorse
it
as
being
the
default
or
something
like
that.
Maybe
I
don't
know-
maybe
it's
unfounded,
but
I
don't
know.
There's.
C
C
For
proto,
where
it
it's
basically
kind
of
like
json,
with
nuances
in
dumb
ways
for
no
good
reason
or
well
for
good
reason
but
whatever,
but
it's
a
human
readable
version
of
what
the
binary
would
output,
and
so
we
could
put
a
caveat
there.
Yeah,
I
think.
Maybe
we
had
the
comment
of
like.
If
we
put
json
we
should.
We
should
caveat
that
the
default
is
binary
and
that
this
is
just
a
human
readable
view
of
what
it
would
look
like
in
json
and
maybe
we're
okay
but
yeah.
I
agree
with
you.
B
B
B
A
C
B
B
A
A
B
A
C
In
some
fashion,
right,
like
a
browser,
can
have
multiple
processes.
C
This
kind
of
goes
into
our
design
a
little
bit
on
resource
right,
yes,
yeah,
like
very
heavily
but
yeah
like
a
browse.
Theoretically,
a
browser
and
a
process
aren't
the
same
thing,
but
a
browser
tab
in
a
process
might
be
in
some
browsers
right
and
a
browser
process
might
be
the
same
thing
in
other
browsers,
but
from
the
fundamental
standpoint
of
what's
the
resource.
C
That's
where
these
nuances
kind
of
come
into
play,
and
we,
I
think
we
just
need
more
guidance
here
a
little
bit,
but
if
we
look
at
the
process
runtime
stuff,
this
is
what
two
806..
B
C
C
C
Maybe
no,
I
I
think
I
I
I
think
we
should
accept
this
with
a
caveat
that,
like
I,
don't
think
we
can
make
progress
on
it
easily
right
now,
given
the
state
of
resource
like,
I
think
this
is
going
to
be
one
of
those
that
just
goes
back
and
forth
until
we
have
a
better
definition
for
what
a
resource
is.
I'm
I'm
on
board
with
the
notion
of
a
browser
as
a
browser
and
not
a
process,
and
let's
keep
those
two
distinct
yeah
same
here.
A
A
C
Well
I'll
take
it,
I
think
I
might
delegate
to
schaeler
eventually,
but
given
that
we're
not
sure
when
we
can
make
progress
on
this,
I
think
it
needs
to
be
either
tigger
in
her
eye
to
say,
like
okay,
here's
a
proposal
for
making
progress
on
what
resources
are.
C
B
All
right,
I
think,
that's
all
the
new
ones
for
this
week
we'll
do
that
pretty
quickly,
that's
cool
anything
else.
You
guys
want
to
raise
that.
We
need
to
talk
about
no
all
right
cool
enjoy
your
day
and
weekend.