►
From YouTube: 2022-11-28 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
B
Thank
you.
Are
you
going
anywhere.
C
A
D
D
All
right,
I
think
we're
gonna
skip
the
triage
section
today
of
new
issues,
because
basically,
over
the
past
two
weeks,
we've
been
asking
folk
to
add
issues
that
are
considered
blockers
for
marking
semantic
convention
stable
and
we
have
like
12
of
them.
D
So
I
guess
it's
not
actually
12
hold
on
we'll
take
a
look.
We
got
a
good
bit
to
go
through.
I
guess
is
what
I'm
saying
and
I
want
to
make
sure
that
we
agree
that
these
are
blockers,
because
we
have
nine
of
them
right
now,
including
the
two
that
are
kind
of
in
progress,
so
I'd
like
to
make
sure
we
get
through
these
so
that
we
can
Mark
things
as
stable
and
then
progress,
cool,
I'm
gonna
wait.
Another
two
minutes
for
folks
to
show
up.
D
So
if
you
have
agenda,
topics
feel
free
to
add
them.
D
E
D
It
go
really
well.
Actually,
it
worked
out
quite
well
lack.
D
D
All
right
cool:
well,
let's
get
started,
shall
we
so
I
wanted
to
start
off
I'm
actually
going
to
time
box
this
to
20
minutes,
okay,
histogram
bucket
boundaries?
We
had
some
discussions
in
the
spec
in
the
spec
meeting.
We
took
this
to
them
about
whether
or
not
we
should
enforce
this
I.
Think
right
now
the
general
consensus
I'm
hearing
and
what
I
hear
from
Prometheus
folks
are
that
it's
okay
to
the
the
wording
that
we
had
is
totally
fine
of.
D
Basically,
when
a
process
is
live,
explicit,
bucket
boundaries,
shouldn't
change
for
a
particular
metric,
but
changing
them
from
release
to
release
to
release
is
totally
fine.
That's
now
there
are
there.
There
are
ways
people
in
Prometheus
might
have
been
able
to
break
themselves,
but
it's
okay
to
say,
like
you
should
be
using
this
other
query
mechanism
instead.
D
So
that
seems
to
be
the
consensus
right
now
and
indeed
like
Prometheus
itself
doesn't
actually
enforce
the
bucket
boundaries.
Are
the
same
from
release
to
release
so
I
think.
That's
where
that
one
sits
I'm
going
to
add
that
to
the
eventual
PR
around
metric
stability,
but
I
wanted
to
actually
talk
about,
attribute
type
alterations
today
and
get
people's
feeling
on
this.
So
this
is
basically
foreign
right
now.
D
I
think
this
is
disallowed,
but
the
type
of
an
attribute
in
semantic
conventions
right
should
that
be
something
that
you're
allowed
to
change
ever
so
I
have
an
attribute.
That's
an
integer
can
I
turn
it
into
a
string
of
an
attribute.
That's
a
floating
Point
number
for
some
reason
can
I
turn
that
to
a
string.
F
D
F
We
did
have
a
is
this
like
talking
expanding
our
talk
from
last
meeting,
where
we
were
wondering
if
I
think
there's
so
many
attributes
right
now.
We
have
that
are
actually
like
error
codes
and
they're
kind
of
treated
as
integers.
D
Yes,
yeah,
that's
exactly
it
so,
like
I'll
give
you
I'll
give
you
two
specifics.
One
is
HTTP
status
codes
right,
there's,
there's
two
issues
here.
So
let's
talk
about
them
independently.
So
the
first
issue
is
whether
or
not
metrics
and
traces
should
share
the
same
attributes.
I
don't
want
to
have
that
discussion
just
yet
we're
not
going
to
talk
about
that.
What
we
are
going
to
talk
about
is,
let's
say
we
Define
HTTP
error
codes
to
be
integers
right
and
then
so
metrics
defines
them
to
Be
Strings,
okay,.
D
G
Have
a
proposal
here
I
think
that
it
hides
it's
living
on
for
Microsoft
I.
Have
it's
I
think
it's
two
combination
of
two
rules,
the
first
one
the
attributes
might
change
from
string
to
something
more
specific.
If
backhand
Street
attributes
of
unknown
types
as
string
can
do
two
string,
condoms
I
think
it
will
give
us
a
chance
to
improve
some
things
like
on
HTTP
site
or
some
mistakes,
or
cover
some
gaps
and
some
implementations.
D
Okay,
let
me
write
that
down
so
actually
are
we
related
part?
So
what
what
was
the
sorry
I
can't
even
pronounce
her
I
can't
even
write
your
name
hold
on
Lynn
Miller
right.
E
D
Okay,
what
was
so
say
that
again
so
I
can
type
it.
As
you
said
it
because
I
think
that's
a
good
proposal.
G
Yeah,
so
the
first
part
is
that
we
can
change
attributes
that
are
strings
to
more
specific
types
like
to
integer,
float
or
I.
Don't
know,
maybe
even
array,
let's
see,
but
as
long
as
there
is
a
second
part
where
we
say
that
back-ends,
when
they
receive
attribute
of
unexpected
type,
they
do
to
shrink
on
it.
D
Again,
sorry,
if
I'm
using
a
okay
cool,
if
I
bought
your
name
there,
yeah
I
did
okay.
G
I
think
it's
it's
like
whenever,
like
it's
the
question
of
how
backhand's
treat
it
right,
if
there
is
a
deterministic
way
and
I
think
the
only
deterministic
way
that
anything
can
be
converted
to
Strings,
but
this
can
be
just
one
type
that
we
default
to
right
unless
we
come
up
with
some
crazy
idea
of
how
to
convert
into
string.
So
you
also
see
that
sorry
strengthened
or
something.
F
C
H
No,
what
I
was
going
to
say
is
I
I
think
this.
This
proposal
would
Miller
makes
sense,
but
the
only
problem
is
that
if
we
decide,
for
example,
to
go
back
then
and
then
like,
because
what
happens
is
most
most
of
the
times
when
you
will
set
up
your
your
dashboard
or
your
alert
query
or
something
if
it's
a
string
in
some
place,
you
have
to
put
it
on
quotes.
So
if
we
do
this
back
and
forth,
then
it
will
break.
It
will
break
people's
queries
and
so
on.
H
C
H
D
G
I
think
it
was
a
big
problem
on.net,
where
we
initially
didn't
support
like
the.net
Primitives
in
in
the
language.
In
the
platform,
they
didn't
support,
attributes
that
are
non-strings
and
there
was
some
Legacy
so
like
going
in
the
past
now
I
think
it's
fixed,
but
some
old
instrumentation
still
stands
during
HTTP
status
codes,
foreign.
D
Okay,
yeah
I
think
that
someone
else
had
a
top
a
comment
right.
Who
was
that.
I
Dress
yeah,
my
one
of
my
concerns,
I,
think
of
Sam
I
brought
up
the
the
last
time
we've
discussed.
This
is
the
span.
Processors
I
feel
like
changing
the
attribute
type,
at
least
in
strongly
typed
languages
where
attributes
are
tied
to
their
types
would
break
span.
Processors.
H
I
guess
it's
more
the
case
like
if
we
go,
for
example,
at
a
stable
version,
and
then
we
realize
that
we
made
a
mistake,
for
example,
and
I.
Guess
it's
not
I
guess
the
discussion
is
not
find
a
way
to
allow
but
to
find
a
way
what
to
do.
If,
if
we
discovered
that
we
made
a
mistake
and
we
need
to
fix
it,
I
guess
if.
A
D
Yeah
I
I.
Actually
this
is
kind
of
what
I
was
trying
to
go.
After
with
my
initial
question,
it
was
basically
like
do
we
think,
there's
ever
a
reason
to
change
the
type
of
an
attribute
that's
legitimate
today,
and
if
it's
just
we're
afraid
that
we
picked
the
wrong
type
initially,
then
I
would
say:
let's,
let's
lock
it
down,
and
if
we,
if
we
need
to,
we
can
suggest
like
hey.
D
Because
that's
flexible
but
I,
think
I
think
we
should
probably
not
like
I'm,
not
hearing.
Anyone
give
a
reason
to
change
to
change
the
the
type
later
outside
of
we
made
a
mistake
and
I
think
it's
okay
to
make
mistakes,
and
there
we
will
find
different
ways
to
fix
that
going
forward,
but
I
don't
think
we
necessarily
need
to
change
the
types
right
now,
because
so,
first
of
all,
I'm
hoping
that
we
won't
make
mistakes
that
are
irreversible
and
number
two
I
expect
us
to
always
make
mistakes.
D
D
We'll
we'll
figure
that
out
we'll
figure
out
a
way
to
deal
with
it,
I'm
actually
comfortable
with
that,
but
I'm
not
comfortable
with,
like
saying
we're
going
to
define
a
mechanism
to
change
attributes
and
then
look
at
all
the
ramifications
like
Trask
mentioned
span.
Processors
are
broken
like
Ludmila
mentioned.
We'd
have
to
rely
on
backend
to
stringing
everything
right,
I
think
there's
just
a
lot
of
friction
there
that
we
don't
want
to
tackle
as
as
a
community
just
yet.
D
G
I'm,
sorry,
it's!
It's
me:
I'm
driving,
I,
I,
muted
myself,
because
I
had
some
comment.
I'm!
Really
sorry
about
this.
C
G
Safe
yeah
yeah,
so
the
I
don't
have
any
objections
on
being
strict
on
attribute
types.
I,
don't
believe
we
will
make
a
lot
of
mistakes
there,
but
overall
I
think
I've.
The
the
concern
I
have
over
being
very
strict
in
general
that
if
we
do
this,
then
every
change
after
that
will
be
breaking
so
I,
don't
want
to
have
YouTube
with
three
returns.
So
we
have
to
find
the
balance,
and
maybe
it's
not
around
the
tribute
types
so.
D
Guys
so
yeah
so
you're
worried
about
us
releasing
tons
of
breaking
changes
and
having
to
do
major
version,
bumps
yeah,
I
hope,
like
I,
don't
see
us
realistically
having
a
major
version,
but
for
a
very
long
time,
which
I
think
means
the
first
time
we
Mark
something
stable
that
that
quality
bar
is
rather
High.
That's
also
why
I
think
we
have
about
12
open
bugs
that
we
have
to
get
resolved
here
to
like
Mark.
D
Our
first,
you
know,
set
of
semantic
conventions,
is
stable,
so
I
I
hear
what
you're
saying
I
also
think
in
areas
where
the
status
like
status
code
is
not
an
integer
which
is
interesting,
there's
actually
generally
Alternatives,
I've
seen
that
make
sense
on
a
like
per
framework
level
to
provide
a
status
code
where
the
actual
issue
is
not
that
the
semantic
convention
defined
like
say
status
code
is
integer.
The
issue
is
that
the
semantic
convention
provided
no
alternative
to
a
status
code
that
was
not
required
right,
I
think
that's
that's
kind
of
anyway.
D
We
can
talk
about
this
because
I
think
there
were
two
issues
around
attribute
types,
but
let's
for
now,
unless
anyone
has
like
a
very
serious
like
you
know,
we
need
to
keep
this
open
and
build
a
mechanism
to
switch
between
attribute
types
from
version
to
version,
let's,
let's
plan
to
lock
that
down
and
keep
it
locked
down,
I
believe,
if
you
look
at
the
current
stability
definitions,
you
are
not
allowed
to
change,
attribute
types
from
version
to
version
without
it
being
considered
breaking
okay,
any
any
last
comments
or
questions
there.
F
D
Yeah
we're
closing
in
the
time
we
started
five
minutes
late,
so
we
have
about
four
minutes
left
the.
If
you
want
to
see
what
our
types
are
supported
in
the
specification,
there
is
a
type
of
stock,
no.
F
I
mean
I
mean
like
I,
see
we
have
them
in
there,
but
we
had
a
discussion
a
couple
weeks
ago
about
whether
or
not
floats
like
different
kinds
of
floats
were
valuable.
I
never
really
did
understand
the
resolution
of
that
you
know
because,
like
then,
we
talked
about
like
we
can't
take
on
ownership
of
all
the
vendors
back-end
implementation
of
types,
and
we
can't
take
on
like
all
languages
handling
a
types
for
example.
F
Javascript
only
doing
floats,
for
example,
python
having
native
big
in
support,
so
I
I
never
got
the
clarity
there
of,
like
you
know,
are
we
like
when
we
say
float
in
the
spec
like?
Is
that
like
an
actual
IE
floater
and
all
that
kind
of
I
mean
I?
Don't
this
is
a
can
of
worms?
Yeah.
D
Yeah
I
would
I
would
go
read
that
just
just
one
thing
to
remember
with
otel
as
a
spec,
we
are
kind
of
the
we
have
to
be
a
bare
minimum
across
all
of
them
a
little
bit
and
we're
also
trying
to
be
somewhat
robust
so
like,
for
example,
with
JavaScript.
We
have
this
whole
thing
where
they
figure
out
how
to
turn
floats
into
integers
for
us
at
various
points,
and
that's
fine
right
in
the
protocol.
D
If
you
look
at
the
Json
protocol
right,
there's
no
such
thing
as
a
integer
in
there,
but
we're
pretending
it's
an
integer
and
we're
expecting
to
be
integer-like.
So
there's
like
in
practice
and
rigorous
and
yeah,
we
need
a
little
bit
of
flexibility.
Here
is
all
I'm
going
to
say
just
generally:
okay,
there
was
another
hand.
What
was
who,
who
was
that.
H
I
was
it
was
me,
it
was
me
I
I
just
wanted
to
to
make
sure
that
I
understand.
So,
if
I
got
it
then
do
we
say
that
now
we
don't
allow
anymore
attribute
change
or
we
still
allow
until
we
are,
the
the
conventions
are
still
experimental.
D
While
the
conventions
are
experimental,
they
are
allowed
to
break
okay.
Gotcha.
However,
I
do
like
the
reason
we
broke.
The
existing
type
in
that
in
the
pr
that
you
raised
was
because
that
was
a
significant
deviation
between
metrics
and
and
traces,
and
we
want
to
make
sure
that
they
are
unified
prior
to
being
stable.
I
I
H
Yes,
no
I
that
makes
sense
I,
yeah
I.
We
also
don't
need
to
to
do
dignity
this
because
you
already
said
but
yeah
not
really
sure
if
we
really
should
make
them
consistent,
because
yeah
I
think
for
for
metrics
the
status
code
being
an
integer
has
no
real
value,
but
but
anyway,
okay.
D
We
I
actually
had
that
as
a
topic
that
I
think
I
took
off
because
I
didn't
think
we'd
have
time.
We
should
talk
well,
actually
it's
this
this
third
one.
Should
we
skip
to
that
now
we
have
four
minutes.
I,
don't
think
it's
enough
for
it,
but
there's
this
notion
of
should
we
have
common
attributes
between
metrics
and
traces
and
should
we
force
them
to
be
the
same?
D
If
you
don't
feel
like
that's
the
case,
I
I'd
encourage
you.
Let's
take
this
for
now.
Take
it
offline.
There's
a
comment
there
about
common
attributes
that
I'm
using
for
this
discussion
write
up
your
thoughts,
I'd
love
to
hear
them
and
I
think
it
deserves
more
than
the
next
two
minutes
in
our
time
box.
So,
okay,
we're
gonna,
we're
gonna
defer
this
for
later.
D
One
thing
we
did
want
to
talk
about,
there's
a
notion
of
moving
metrics
to
be
based
on
seconds
as
opposed
to
microseconds.
This
is
a
request
from
I
think
Prometheus
the
community
because
they
default
to
seconds
as
their
base
unit
open,
Telemetry
defaults
to
microseconds
I.
Believe,
that's
because
we,
you
know,
pulled
our
defaults
from
open
census
who
also
defaults
to
microseconds
all
of
the
reasons.
The
compelling
reasons
why
to
use
microseconds
that
I
can
think
of
actually
don't
apply
because
we're
tracking
floats
anyway
does
anyone?
A
Yeah
I
I
know
there
are
systems
using
milliseconds,
not
micro
seconds,
and
they
only
support
the
integer
today.
So,
if
all
of
a
sudden,
we
change
it
to
a
second,
the
systems
that
that
can
support
floating
point
would
suffer.
D
Okay,
so
I
was
pretty
sure
that
the
reason
we
use
milliseconds
sorry,
it's
milliseconds
for
latency
in
metrics.
That's
right.
We
do
use
microseconds
for
traces.
We
use
milliseconds
for
metrics
whatever
anyway,
that
was
kind
of
what
I
was
afraid
about
like
if
we
know
of
active
systems
that
rely
on
this
and
turn
it
into
an
integer.
D
A
Time
I
know
one
like
the
Microsoft
internal
system.
They
they
started
with
integer
like
about
15
years
ago,
although
folks
I
did
ultimately
double
later,
but
integer
is
still
considered
as
much
more
efficient
from
the
competition
and
storage
perspective.
A
Another
thing
related,
apparently,
if
you
look
at
the
Texas
related
budget
histogram,
we
already
Define
the
buckets
based
on
the
assumption
that
durations
are
milliseconds,
so
we
have
the
value
of
like
5,
10,
25
75.
If
all
of
a
sudden
we
can
talk
settings,
then
the
default
package
would
make
less
sense
for
any
duration.
D
Right,
but
so
one
of
the
things
we
already
agreed
on
is
we
can
actually
change
those
bucket
definitions
at
any
time
and
it's
not
considered
breaking
yeah,
so
we
could,
like
I
I,
would
say
that
we'd
have
to
change
both
of
them
at
the
same
time,
yeah.
D
The
the
interesting
thing
is
okay,
so
right
now
the
way
open,
Telemetry
defines
histograms
those
we
actually
we
we
store
them
as
floating
points,
client-side,
so
I
think
most
of
the
benefits
of
storing
as
integers
is
lost
in
the
client
side,
but
could
be
gained
back
service
all
right,
we're
at
our
time
box.
D
Thanks
for
raising
that,
can
you
can
you
make
comments
on
this
issue
to
that
effect,
because
I
think
I'd
like
to
collect
instances
of
back
ends
that
would
really
struggle
with
this
to
see
how
much
the
community
would
be
impacted.
If
we
move
to
seconds
like
again,
it's
it's
it'd,
be
a
really
good
opportunity
to
align
with
Prometheus.
But
if
we
feel
like
this
would
leave
other
metric
back
ends,
kind
of
left
out,
I
think
we'll
we
might
need
to
go
to
them
and
talk
to
them
about
their
defaults
too.
D
Okay,
we
had
a
bunch
of
comments
here,
so
these
Riley,
for
example,
with
this
one
I
think
if
you
can
raise
this
we'll
see
if
we
have
time
after
the
discussion
from
Ted.
Otherwise,
if
you
can
open
a
bug
about
this,
we
can
comment
there.
Offline,
sound,
good,
oh
well.
Okay,
all
right,
Ted!
Take
it
away.
B
All
right
all
right,
so
let
me
share
my
screen
here:
oh
or
you
can
pop
over
to
that
video
or
video
document
okay.
So
this
is
just
trying
to
break
down
how.
Realistically
we
could
process
all
of
our
existing
semantic
conventions
and
mark
them
as
stable
I
only
went
through
the
semantic
conventions
for
tracing.
We
don't
really
have
semantic
conventions
for
metrics
or
logs
written
down.
B
As
far
as
I
can
tell,
we
do
have
resources,
those
seem
pretty
stable
to
me
or
at
any
rate
they
don't
seem
to
be
as
complicated
necessarily
as
processing
some
of
these
other
domains.
That
could
be
wrong,
but
just
looking
at
the
ones
we've
defined
in
tracing
in
terms
of
actually
getting
a
working
group
together
to
process,
these
I
propose
a
kind
of
three-quarter
system,
so
we
actually
spend
the
first
quarter
a
whole
quarter.
B
Trying
to
organize
the
working
group
and
the
reason
for
that
is
just
to
really
give
people
a
heads
up
that
this
is
coming
because
I
think
it
takes
time
to
actually
reach
out
to
people
and
for
those
people
to
talk
to
their
managers
or
for
managers
to
find
people
and
then
usually,
once
that
happens,
they
then
actually
have
to
get
approval
to
do
this
and
for
most
companies.
That's
that
sound
like
a
quarterly
cycle.
B
So
if
we
want
these
working
groups
to
actually
be
very
concentrated,
as
opposed
to
meeting
just
like
once
a
week
and
very
slowly
working
through
this,
if
we
want
these
working
groups
to
actually
be
doing
quite
a
bit
of
work
to
to
try
to
hammer
these,
these
proposals
out
quickly,
I
think
we
need
to
do
work
up
front
to
ensure
that
people
are
actually
going
to
have
time
for
that
so
I'm
proposing
we,
we
spent
a
quarter
trying
to
to
organize
these
groups
and
I,
don't
think
that'll
be
a
problem,
because
I
think
we'll
have
plenty
on
our
hands
once
we
get
rolling
with
whatever
we've
already
kicked
off
so
one
quarter
to
organize,
then
one
quarter
to
actually
do
the
work
so
I'm
proposing
that
the
working
group
would
have
six
weeks
to
put
together
all
the
oteps
that
they
want
to
submit
to
the
community.
B
That's
actually
a
very
short
timeline
compared
to
how
fast
we've
moved.
That's
usually
because
in
the
past,
we're
moving
at
a
Cadence
of
like
one
meeting
a
week
and
not
necessarily
a
huge
amount
of
process
in
the
meantime.
B
But
if
we
could
get
these
groups
organized
and
be
very
concentrated
on
it,
my
hope
is.
We
could
get
get
real
proposals
out
there
in
six
weeks
and
then
have
four
weeks
for
public
review
where
we
we
try
to
promote
it
ahead
of
time
and
say
like
this:
is
the
public
review
window?
B
Please
get
your
reviews
and
comments
in
within
this
window
because
we
may
very
well
Market
a
stable
at
the
end
of
this,
so
try
to
have
a
clear
public
commentary
window
of
a
month
and
I
didn't
put
in
there,
but
there's
12
weeks
and
a
quarter
I
believe
so
that
would
give
us
two
weeks
after
that
period
closes
or
any
spillover
to
actually
get
this
stuff
committed
and
actually
marked
a
stable
and
like
released
in
the
spec.
B
So
one
quarter
to
actually
do
the
work
and
then
the
third
quarter,
the
part
we
don't
often
think
about
organizing
or
haven't
thought
too
hard
about
how
we
would
organize
it.
Yet
is
implementation
once
we
actually
update
this
stuff
in
the
spec
I
think
we
need
to
move
immediately
to
actually
updating
all
of
the
instrumentation
we
currently
provide.
We
don't
want
that
to
lag.
We
don't
want
to
lean
on
the
maintainers
of
these
repos
to
do
it,
because
actually
maintainership
of
our
contrib
repos
right
now
is
like
very
shaky
and
uneven.
B
So
this
would
also
be
a
chance
to
to
work
with
the
main
language
sigs
to
kind
of
address
any
Shenanigans
going
on
there
with
any
of
these
things
that
we're
maintaining.
So
it
would
be
a
path
to
not
only
improve
them
and
get
them
up
to
snuff
but
kind
of
review,
how
we're
maintaining
them
and
making
sure
there
actually.
B
On
the
other
end
of
the
line
for
all
of
these,
when
someone
files
an
issue,
so
that's
that's
the
proposed
work.
The
other
question
is
well
how
many
of
these
can
we
do
and
in
what
order
should
we
try
to
tackle
them?
So
if
you
go
down
to
timeline,
I've
listed
what
I
believe
is
currently
in
Flight,
which
is
HTTP
messaging
and
client.
Rum
I'm,
calling
rum
client
here
on
the
client
side,
we're
basically
focusing
on
the
browser
right
now.
So
that's
the
the
implementation
of
the
client
domain.
B
We're
trying
to
hammer
out
the
specifics
for,
and
the
messaging
domain
I
believe
has
mostly
been
focused
on
Kafka
and
rabbit
and
queue
I.
Think
cloud
events
also
I
didn't
list
that
there,
but
those
are
the
actual
implementations,
we're
focusing
on
and
then
HTTP
I
think
still
has
maybe
some
little
Shenanigans
left
in
it.
B
To
get
addressed,
so
that's
that's
our
current
ball
of
work,
so
the
goal
would
be
to
try
to
get
the
spec
work
for
that
completely
done
in
q1
and
then
in
q1
We
Begin,
the
whatever
we
want
to
call
it
preparation,
working
group
preparation
period
for
the
next
set
of
stuff.
It
seemed
perhaps
logical
to
me
that
we
try
to
just
since
we're
already
working
on
HTTP
and
messaging,
and
things
like
that
to
to
go
with
the
network.
B
The
other
network
and
client
related
work,
since
that
works
just
seemed
like
the
most
relevant
to
the
work,
we're
currently
focusing
on
Network,
RPC,
grpc,
being
the
main
implementation
of
our
PC
that
that
we
do
and
then
IOS
and
Android
perhaps
caveat
on
if
we
can
get
apple
involved
in
iOS
and
and
I'm,
not
sure
who
we
need
for
Android,
so
that
that
would
be
what
we
kick
off
in
q1
and
Q2
possibly
spend
that
quarter.
B
Looking
at
the
database
stuff,
we
I'm
always
been
like
slightly
concerned
about
the
fact
that
we
have
like
a
database
domain
like
what
the
hell
does
that
even
mean,
and
then
we
have
something
of
implementation.
We
have
like
examples
of
how
redis
and
and
we
have
some
bits
about
Cassandra
and
my
sequel
in
there,
but
that
this
domain
I
actually
think
is
the
one.
If
there's
any
of
these
domains,
we
actually
like
tear
apart
quite
a
bit
potentially
I'm
thinking.
It
might
be
this
one.
B
So
I
think
this
is
a
biggie.
Are.
D
B
D
Yeah
I
I'm
also
so
a
few
things
a
few
things
here.
One
I'm
worried
about
networking
for
that
specific
reason,
as
well.
I
think
going
after
HTTP
and
RPC
makes
a
hell
of
a
lot
of
sense
and
covers
90
of
our
networking
needs.
But
networks
in
general
are
incredibly
complex
and
I.
Think
they
don't
want
I,
don't
know
how
deep
you
want
to
go
in
that
rabbit
hole,
but.
B
C
B
I
would
not
want
to
mess
with
this
if
we
could
avoid
messing
with
what
we've
already
done
here,
because
it
seems
pretty
fundamental,
but
it
affects
everything.
So
we
should
at
least
we
it's
still
marked
as
experimental
so
like.
We
have
to
at
least
look
at
what
we've
put
there
and
and
try
to
Market
as
stable
for
TCP
I
I.
D
All
right,
so,
let's
call
this
TCP
then
instead,
like
I,
think
again
like
in
the
sense
of
getting
things
done,
the
the
more
we
can
scope
a
domain,
the
better
and
these
big
broad
domains.
I
agree
with
you,
I
think
they're
they're
somewhat
dangerous.
My
I
asked
this
question
before
and
I
kind
of
want
to
talk
this
one
out
a
little
bit.
What
is
the
definition
of
done
for
each
of
these
stages?
This
one
I
think
is:
is
the
clearest
like
hey,
we
Market
a
stable
right.
C
D
Then,
in
the
third
quarter,
I
also
kind
of
want
to
understand
what
this
looks
like
like
for
for
now.
One
thing
I
want
to
call
out.
We
do
TC
reviews
of
implementations
for
like
metrics,
like
we
did
TC
reviews
for
traces
and
metrics
right
and.
I
D
The
TC
review
what's
interesting
is
everyone
falls
apart
with
the
same
set
of
problems,
and
it
was
really
easy
to
do
more
than
one
review
in
the
sense
of
you
would
look
for
the
same
set
of
problems
in
the
same
set
of
code,
because
it's
very
similar
I
expect
that,
to
be
the
case
say
with
HTTP
semantic
conventions.
D
For
example,
I
expect
grabbing
HTTP
route
to
be
one
of
the
hardest
problems
in
instrumentation
to
solve
the
good
route
number
right,
yes,
and
so
I
expect
having
a
consistent
set
of
people
to
review
that
across
instrumentation
might
be
useful.
Does
it
make
sense
for
us
to
kind
of
have
the
expert
committee
linger
for
a
time
in
that?
Third,
you
know
implementation
to
kind
of
assist
with
that,
at
least
at
a
review
capacity,
not
necessarily
anyway
like
calling
that
out.
Yeah
there's
raised
hands
so
I'll
stop
talking,
I
think
who's
next.
D
B
I
would
propose
this
also
covers
metrics,
okay
and
Vlogs.
We
have
all
three
of
these
things
now
so
and
metrics
then
also
kind
of
bleeds
into
resources,
presumably
right.
D
Yes,
absolutely
we
we
actually
there's
a
few
fundamental
questions
with
metrics.
We
still
have
to
answer
like
what
labels
and
resources
become
time
series
labels
that
sort
of
thing
yeah.
B
D
A
B
F
I
was
just
going
to
say,
I
think
having
a
case
study
like
by
actually
like
going
through
the
full
process
of,
like
you
know,
focusing
on
one
would
be
useful,
of
course,
like
you
should
always
have
an
eye
for
breath,
but
I
think
we're
going
to
take
on
too
much
ownership
if
we
try
to
handle
like
the
entire
breath
before
solidifying.
One
I'd
rather
just
know
what
the
process
looks
like
for
one
verse
before
we
try
to
do
everything.
Yeah.
B
The
the
only
caveat
I
would
put
in
there
is,
we
have
already
started
a
pile
of
these
things,
which
are
the
stuff
listed
under
current.
Are
the
things
that
already
have
working
groups
that
are
they're
hacking
their
way
through
it
so
I
think
normally.
C
B
D
Not
starve
them
of
attention
can
I
ask
a
different
question:
can
we
okay,
so
I
want
to
focus
on
HTTP,
specifically
because
I
think
it's
the
most
impactful
of
the
ones
in
flight
and
I?
Think
it's
the
furthest
along
and
I
personally,
really
like
it's
like
where
it's
got
gotten
to
I.
C
D
Think
there's
the
Shoring
up
of
metrics
and
traces
that
has
to
happen
and
I
think
that's
a
good
one
to
focus
on
initially.
My
question:
is
you
know
if
you
look
at
your
timelines,
let's
pretend
like
we
can
get
HTTP.
Let's
pretend
like
say
this
second
quarter
work
that
you're
talking
about
is
something
we
can
complete
in
q1.
D
B
D
The
I
mean
my
fear
is
actually
whether
or
not
we
have.
We
have
a
large
community,
but
do
we
have
enough
decision-making
powers
to
pull
this
all
in
in
parallel?
The
way
that
you
want
to
hear
yeah,
that's
something
that
I'm
worried
about,
but
the
other
thing
I'm
a
little
bit
concerned
about
like
I,
think
we
want
more
definition
here
of
the
working
group
preparation
to
alleviate
that
right.
So
this
would
be
like
to
form
a
working
group.
What
are
the
requirements?
D
We
want
experts
that
people
recognize
that
are
experts
in
the
field
right,
so
people
who
do
monitoring
of
that
thing,
and
maybe
people
who
work
on
that
thing,
but
I
think
people
who
do
monitoring
of
the
thing
are
more
valuable
and
then
the
second
thing
would
be
probably
someone
who
can
one
or
two
decision
makers
on
the
spec
where,
if
you
get
their
approval,
you
can
almost
green
light
all
your
PR's
through,
because
you
know,
if
you
have
enough
approver,
spec
approvers
involved
with
the
committee.
D
D
Making
right
so
like
I
think
including
that,
specifically
in
this
proposal,
is
going
to
be
necessary
and
that
should
tell
us
how
parallel
we
can
be,
because
if
you
can't
get
enough
spec
approvers
to
be
part
of
the
meeting,
that
likely
means
we
can't
parallelize
anymore,
and
we
shouldn't
kick
that
off.
B
So
we've
got
I
got
a
chat
and
an
the
agenda,
if
you
in
mind
just
hopping
over
to
this
project
management,
doc,
real,
quick,
Josh.
B
So
this
this
dovetails
with
what
you
were
just
talking
about.
We
have
not
really
implemented
this
process
yet
because
we
haven't
had
people.
I
am
currently
trying
to
Wrangle
together
some
some
product
managers
to
help.
You
know
oversee
this
and
help
us
work
our
way
through
it,
but
this
is
very
relevant
to
what
you're
just
saying.
So
this
is
like:
how
do
we
start
spec
projects
in
general?
How
do
we
propose
them?
What
are
the
requirements
so
in
q1?
B
Basically,
it
would
be
to
get
this
this
thing
fully
fleshed
out
as
far
as
these
requirements,
which
means
we
also
need
to
have
some
organizing
work
put
in
there
like
it's,
not
just
like
these
things
must
be
filled
out
or
you
can't
start
it's
it's.
What
organizing
work
do
we
need
to
do
to
ensure
that
these
things
actually
will
get
filled
out
and
people
will
know
that
we're
doing
it
so
Twitter,
you
know
actively
reaching
out
to
Community
member
organizations
actively
reaching
out
to
the
database
manufacturers.
B
What
have
you
reaching
out
to
those
communities
we
reached
too
far?
We
then
the
edge
of
the
internet
shows
up
and
I'm,
not
sure
how
much
of
that
we
want.
But
you
know
that.
C
D
B
D
I've
never
heard
it
called
the
edge
of
the
internet,
but
I
like
that
term.
Try
to
be
polite,
yeah,
interesting,
yeah,
I.
Think
like
like
this.
This
does
make
sense
by
the
way
we
tried
to
follow
this
process.
For
this
specific
working
group,
yeah
actually
how'd
that
go
well.
We
have
a
project
board
and
we
have
people
and
we
have
a
meeting
yeah
so
we'll
see
how
the
impact
is,
though,
but
I
wasn't
I
actually
wasn't
planning
for
this
group
to
be
done.
D
You
know
in
a
short
time
period
Okay,
so
I
I
like
this
as
the
as
the
thing
I'd
like
to
be
very
crisp,
though,
like
again
I
think
at
a
minimum.
It's
not
just
about
having
like
a
I,
think
what
you
say,
group
of
designers,
a
portion
of
the
TC
needs
to
be
aware
and
participate.
I
I
want
numbers.
You.
D
B
For
if
you
look
down
under
Staffing
required
Staffing
that
at
least
two
sponsoring
yeah
could
link
to
that
from
the
top.
So.
B
That's
all
that
we've
we've
written
out
it's
there.
A
B
Be
a
lead,
there
has
to
be
at
least
two
members
of
the
TC.
There
has
to
be
engineers
in
at
least
two
languages
who
have
committed
to
writing
prototypes
and
the
made
approvers
of
those
language
committed
to
reviewing
the
prototypes.
D
Well,
so
here's
the
question:
if
we
come
into
contributing
right:
where
does
it
show
this.
D
Okay,
now
to
get
your
PR
merged
right
more
than
two
approvals
right.
Can
we,
let's?
Why
don't
we
add
a
requirement
for
a
third
spec
approver,
not
a
TC
member,
but
a
third
spec
approver?
That
means
every
single
committee
will
have
three
approvers,
which
means
you
get
the
more
than
two
and
they
have
to
be
three
people
from
different
companies,
and
then
that
means
that,
basically,
the
committee
can
almost
Act
get
things
into
the
spec,
basically
almost
independently,
so
that
whole,
like
we
wait
for
end
days
for
Community
feedback.
You
already
have
your
approvals.
D
A
D
A
It
might
help
on
the
general
by
career
Hall,
but
I,
don't
understand
how
it
will
help
semantic
convention
like
messaging
because
messaging,
the
pr
I've
seen
this
node
is
approving
that
people
ask
questions
and
they
don't
seem
to
want
that
to
go
through
which.
A
My
name
is
messaging
when
I
saw
those
PR
Audrey's
in
autism,
because
I'm
not
expert
I
I,
don't
know
whether
I
can
reveal
them
or
not.
I
can
probably
review
some
basic
typo
and
and
ask
a
general
question,
for
example,
of
certain
type,
whether
it's
a
line
but
for
Database
The,
Physician
I,
don't
have
a
strong
opinion
and,
and
also
would
you
be
able
to
review
those
PRS
and
are
implemented.
So
that's
a
problem.
D
I'm
suggesting
that
we
have
people
who
we
so
when
we
form
these
committees,
we
make
sure
we
have
people
who
are
invested
in
the
process
who
understand
what
these
things
mean.
Who
are
part
of
that
expert
committee?
D
Who
can
make
that
approval
and
make
that
judgment
and
can
look
at
complaints
and
kind
of
evaluate
them
appropriately,
but
we
make
sure
we
have
enough
approvers
involved
with
the
process
that
these
things
can
get
through.
So
we
don't
run
into
there's,
like
you
know,
12
experts
working
on
a
semantic
convention,
but
none
of
them
are
actually
approvers,
and
so
they
send
something
that
no
one
feels
comfortable
clicking.
The
approve
button
for
yeah.
D
B
Experts,
like
their
role,
is
to
Shepherd
this
thing
through,
so
that
you
don't
end
up
in
this
situation,
where
you
go
public
and
like
all
of
the
working
groups,
state
has
been
built
up
in
basically
a
group
of
Outsiders
and
like
no
one
on
the
open,
Telemetry
side
has
any
like
clue
what
they
went
through
to
to
get
to
to
where
they
are
but
and
I
saw
James
had
his
hands
up,
but
just
to
say,
I
do
to
address
what
Riley
and
you
are
saying,
I
I
think
part
of
this
is
when
we
kick.
I
B
People
are
right
to
to
be
shy
about
I
appreciate
that
people
are
shy
about
clicking
that
button
when
they
don't
feel
like
they
understand
what
it
means.
So
it's
maybe
just
we
have
to
solve
it
a
different
way.
F
Oh
no
I
was
just
going
to
say
for
like
when
we
get
these
domain
experts
in
there
I
just
make
sure
they
have
clear
expectations
as
far
as
what's
required,
like
anyone.
That's
like
for
an
example,
a
domain
expert
in
you
know
like
postgres
or
something
doesn't
necessarily
have
to
be
a
domain
expert
in
otel.
So
just
want
to
make
sure
that,
like
you
know,
we
have
these
expectations
set
like
when
we
had
the
reviewer.
So
it
lowers
the
barrier
of
entry
for
experts
and
yes,
yeah,
okay,
right.
F
B
B
So
an
example
of
this
I
I
basically
played
this
role
for
the
rum
working
group,
because
they're
they're
I
don't
believe
there
were
any
maintainers
Riley
you
might
have
been
around
for
that
one
I
forgot.
B
But
what
happened
is
you
have
these
rum
experts
come
in
and
they're
very
good
at
how
run
client
instrumentation
should
work
and
all
the
noodling
details,
but
in
their
heads
this
was
something
totally
wholly
separate
from
like
tracing
and
metrics
and,
like
the
other
stuff
we
do,
and
so
my
role
in
that
project
wasn't
be
a
rum
expert
but
it'd
be
like
no.
No,
no,
no
like
this.
Whatever
we're
defining,
we
want
to
Define
in
terms
of
The
Primitives.
We
already
have.
B
We
want
this
to
integrate
with
all
the
other
stuff
and
that
caused
them
to
have
to
like
pivot
a
little
bit
at
how
they
looked
at
the
world,
and
so
we
should
kind
of
expect
all
these
outside
experts
to
not
be
used
to
the
kind
of
unified
holistic
thing
we're
doing
here
and
that's
where,
like
the
TC
Hotel
spec
group
will
help
them
get
through
it.
The
other
thing
is
it's
like
80,
90
percent,
whatever
we
can
Define
it
in
terms
of
what
we
already
have
I
find
for
some
of
these
things.
B
There's
this
weird
outlier,
for
example,
with
rum.
It
was
sessions,
concept
of
like
sessions
and
sessions
IDs.
We
had
nowhere
to
put
that
that
didn't
break
some
rule
we
had
already
set,
and
that's
the
other
place
where
it's
like
it
is
not
possible
for
an
outsider
to
push
through
a
big
change
like
that.
In
my
experience,
like
you
have
to
you,
you
have
to
have
somebody
bought
in
who's
fine
kind
of
rolling
around
with
the
TC
on
on
this
stuff.
D
All
right
so
I'm
going
to
call
the
time
box
right
now
a
little
bit
on
this.
What
I?
Let's?
Let's
talk
about
action
items
and
what
we're
doing
next
so
Ted
I
think
like
I
I,
like
I,
like
where
the
document
started,
I,
think
that,
like
I
said,
I
want
to
have
more
specifics
and
details
in
it
and
I
think
you
should
take
that
to
the
this
I
guess
the
specification
meeting
next
yeah
yeah
that'd
be
great
and
then
for
everybody
in
terms
of
Telemetry
definition,
stability.
D
We
do
have
this
set
of
blockers
that
we're
tracking
around
semantic
conventions.
There's
a
lot
and
I'm
not
surprised
by
this,
because
metrics
just
got
marked
stable
around
metrics
and
Trace
that
we
need
to
preserve,
and
so
please,
like
open
blockers
if
you're
aware
of
them
or
help
pick
up
tasks
and
drive
them
through
I
listed
a
few
here
to
that
are
top
of
mind
for
me
to
kind
of
drive
through
that
will
kind
of
walk
through
and
we'll
continue
discussing
in
the
issue.
D
But
if
anyone
can
help
kind
of
pick
up
one
of
these
and
drive
it.
If
you
want
to
own
something,
just
ping
me
and
I
can
make
you
the
owner
of
a
task
or
of
a
an
issue
to
track,
otherwise
we're
just
going
to
drive
through
as
many
of
these
as
possible
and
start
raising
them.
These
will
likely
have
to
go
through
our
spec
committee
meeting
to
discuss
or
you
know,
get
approvals
there,
but
we
got
a
good
bit
to
churn
through.
D
A
Apply
something
Josh,
so
how
how
do
we
know
whether
the
issues
are
bloggers
for
them?
I
created
many
patients
related
to
management
and
and
I
I
asked
you.
You
just
told
me
to
mark
all
these
issues
as
bloggers
in
the
board,
but
I'm
not
sure
if
my
understanding
is
aligned
with
everyone
else
here.
So
what?
If
I
open
some
issue
that
is
not
considered
as
blocker
for
everyone
else
here.
D
Then
I
think
that's
what
we
discuss
on
the
on.
The
issue
is
like:
if
we
think
something
is
not
a
Blocker,
we
would
say
hey
this,
isn't
a
blocker
we're
going
to
table
this,
that
yeah
I
think
the
ones
that
I
looked
at
so
far,
I
looked
at
about
90
of
them,
I
think
I
missed
two
that
I
didn't
get
to
before
the
meeting.
I
think
you're
right
that
they
are
blockers.
We
have
to
make
a
decision
on
I,
don't
think
we
have
to
solve
the
entire
problem,
but
there
are
pieces
of
it.
A
D
That
is,
that
is
an
acceptable
thing
to
do.
Yeah
and
but
yeah
I
think
the
ones
that
I'm
most
worried
about
actually
are
around
aligning
our
semantic
conventions
with
say,
open,
metrics
and
Prometheus,
and
then
aligning
our
metric
conventions
with
our
Trace
conventions.
I
think
those
are
the
two
that
are
most
likely
to
cause
breaking
changes
to
what
is
marked
experimental
now,
and
so
those
are
the
ones
I'm
most
worried
about
yeah
cool.
Thank
you
all
right,
I'm
gonna
give
everyone
five
minutes
back.
D
We're
gonna
try
to
rigorously
stick
to
our
time
boxing,
so
we
can
be
efficient
and
please
take
things
offline
comment
on
issues
and
comment
on
Ted's
proposal
which
I'm
excited
for.
D
And
just
so,
we
all
are
aware
by
the
way
holidays
are
coming
up.
I
think
we
will
have
to
cancel
one
of
our
meetings
in
December
I,
hopefully
not
both
I'm
taking
odd
Vacations,
so
I
will
apologize
for
that
when
I'm,
not
here,
maybe
Ted
can
run
the
meeting
if
there's
one
prior
to
the
holiday.
D
That
makes
sense
to
have
would
like
to
try
to
make
as
much
progress
towards
HTTP
being
more
stable
as
possible
before
the
new
year
I'm,
hoping
that
we
can
sometime
in
q1,
get
HTTP
Mark
to
stable,
and
we
have
that
huge
churn
of
issues
to
get
through.
So
just
to
keep
everyone
aware
all
right
thanks.
Everybody
have
a
good
day
thanks,
Laura
bye.