►
From YouTube: 2023-02-14 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
A
Ludmilla
I
learned
something
from
you
the
other
day
of
how
to
get
to
the
different
repos
in
because
I
don't
know
why
it
hasn't
been
remembering
like
it's
been
really
bad.
I
keep
having
to
do
open.
Telemetry,
then
open
toiletries
back
and
I
saw
you
do
Dash
specifications,
bash
instrumentation
and
it's
brilliant.
Thank.
A
Yeah
I
wanted
to
especially
it
says:
James
is
here
to
I,
don't
know
James.
If
you
had
a
chance
to
look
at
Lynn
Miller's
comments
on
this
PR
yeah.
D
Yeah
I
just
had
a
quick
look,
then
yeah
I
I'm
not
sure
how
I
feel
about
some
things,
but
I
I
do
get
what
you're
saying
like
I
like
the
idea
of
being
able
to
generate
the
like
metrics
from
the
spans.
That
kind
of
thing
it
also
doesn't.
Quite
it's
not
intuitive
to
me
to
Define
the
metric
this
specifically
in
this
HTTP
common
file.
It
seems
like
you're,
specifying
the
metric
attributes
and
the
metric
requirement
levels,
which
seems
somewhat
counter-intuitive
to
me
and
and
I.
D
Don't
think
it's
really
stated
either
that
that's
what's
happening.
Correct
me
if
I'm
wrong
there,
but.
C
D
Well,
yeah
I,
obviously,
there's
going
to
be
some
attributes
that
are
on
traces
that
aren't
on
metrics,
right,
I,
I,
guess
that's
where
I'm
coming
from
is
that
but
you're
coming
from
the
perspective
of
those
will
be
defined
in
the
Trade
Center
convention
rather
than
the
common
selection
of
HTTP.
But
then
then,
I
I
think
in
the
future.
D
That
will
arise
a
problem
where
you
want
to
have
attributes
on
logs
and
then
you're
going
to
have
to,
but
those
attributes
are
only
defined
in
the
Trace
semantic
convention
and
not
in
the
common
section,
even
though
they're
used
by
two
signals,
so
it's
like
I
just
and
also
I,
think
it
could
we're
just
looking
at
HTTP
here,
but
like
that
kind
of
structure
like
I,
can
see
it
being
a
little
bit
brittle
across
all
the
different
semantic
inventions
as
well.
D
C
And
I
I
hear
you
so
why
I
chose
this
is
because
I
thought
it's
useful
to
describe
attribute
specific
signals
in
at
in
Signal
folders
right,
so
that
we
don't
say
that
high
cardinality
attribute
appears
in
HTTP
common
I
I
also
understand
what
you're
saying
about
the
other
signals,
but
the
more
I
think
how
HTTP
attributes
would
appear
on
logs.
C
Nothing
and
like
why
would
you
put
HTTP
URL
there?
What
does
it
mean?
It
means
nothing.
So
to
me
it
sounds
like
there
is.
Yes,
there
is
a
general
attribute
registry,
which
I
think
is.
The
area
is
boiling
down
in
some
other
working
groups,
and
then
there
is
this.
There
are
semantic
conventions.
How
those
two
are
related.
We
don't
know
and
I
realized
that
maybe
this
is
not
the
final
picture
and
how
this
yaml
files
look
like
and
are
organized,
but
they
are
not.
They
are
not
the
spec.
A
Sure
that's
what
I
was
going
to
ask
is:
is
there
something
James
that
you
could
open
either
in
spec
repo
or
build
tools,
repo
to
continue
this
discussion
to
not
lose?
You
know
that
thought
in
context,
but.
D
A
Only
because
selfishly
this
one
PR
closes
out
like
four
of
our
blocked
on
blockers
for
HTTP
semantic
stability.
D
Yeah
yeah
no
I,
I
I'm
on
the
same
page,
I
really
want
it
to
be
stable
as
well.
Like
that's
going
to
help
us
enormously,
so
I
don't
yeah.
We
can.
We
can
I'm
very
much
happy
to
to
discuss
that
in
like
the
build
tool
side
of
things
and
not
not
bloggers
back,
hey,
y'all,
yeah,
so
I'll
put
a
comment
on
that.
I
can
resolve
those
conversations,
yeah
yeah.
C
A
I
will
try
to
get
Josh,
maybe
one
more
approval
on
this
and
then
I'll
ask
for
a
merge.
I,
don't
think.
C
The
tour
shuffling
kids,
unfortunately,
any
small
changes
in
yamo
lead
to
change
in
order
of
high
tributes,
so
I.
C
But
no,
but
I
was
go.
I
created
one
link
to
this
pull
request
and
if
you
just
had
a
comment
there
that
stable
ordering
is
much
appreciated
unless
something
changes,
semantically,
like
her
requirement
level
or
a
name
right,
then
I'm
happy
to
address
all
of
them
in
one
place.
A
Yes,
this
one
so
we're
on
hold
for
instead
of
I
mean
most
of
our
changes
for
the
ECS
decision,
and
but
there's
a
couple
that
I
think
we
can
continue
making
Improvement
on
regardless
making
progress
on
regardless.
C
A
No,
oh
I
didn't
mark
the
PR
ready
for
review
this
one
I
I
personally
think
we
should
do
regardless
of
the
ECS
alignment.
I
think
that
user
agent
breaking
user
agent
is
much
less
disruptive
compared
to
Breaking
other
HTTP
things
and
we've
had
the
comment.
A
We've
had
a
couple
cases
already
in
this
repo,
where
it
would
be
helpful
to
share
it
and
then
also
the
whole
user
agent
thing
I,
just
I
didn't
know
this
user
agent
is
going
away
or
the
big
string
is
going
away
and
it's
being
broken
up
into
like
small
components.
A
So
in
the
future,
probably
we
would
capture
user
agent
Dot
browser
user
agent
version
things
like
that
separately.
Anyways.
A
I
guess
the
only
question
is
what
to
name
this
ECS
names
it
original
matesh
was
suggestion.
Well,
we've
got
if
we're
doing
url.4,
maybe
user
agent.4,
but
I
think
we're
only
going
to
do
url.4
if
we
do
ECS
anyway,
in
which
case
we
would
do
useragent.original.
A
I
thought
maybe
original
was
okay,
because
it's
kind
of
like
original,
like
the
old
school
original
user
agent,
you
could
think
of
it.
That
way,.
A
So
I'll
probably
just
mark
this
ready
for
review
and
Trend
I'm
gonna
I'll
raise
this
in
tomorrow's
spec
meeting.
A
I
guess
that's
probably
a
good
thing
to
discuss
is
what
you
all
think
would
be
most
beneficial
to
bring
to
the
spec.
At
this
point.
A
We
wanted
to
do
it
end
of
this
week,
but
I
don't
seeming
unrealistic.
We
may
meet
with
them
tomorrow.
Riley
set
something
up
for
tomorrow.
I
think.
E
E
A
Didn't
add
the
yeah,
the
public,
the
the
big
list
of
everybody
I'm.
A
A
So
until
someone
tells
me,
that's
literally
not
possible,
that's
the
those
are
the
dates
for,
but
yeah
I
think
everything
will
flow
from
that
ECS
decision.
C
C
Yeah
so
I've
done
some
research
so
like
the
the
context
is
that
they
currently
have
http.client
AP
to
capture
forwarded
AP
address,
but
unfortunately,
with
the
forwarded
header,
it's
not
AP
anymore.
It's
basically
a
list
of
strings
along
the
were
a
string,
so
it
can
be
if
you
click
on
the
non-identifiers
in
the
RFC.
C
So
it
can
be
an
AP
address,
it
can
be
an
AP
address
port
and
it
can
be
a
string
an
obfuscated
name.
So
it
feels
to
me
that
IP
forwarded
AP
and
ECS
or
client
AP
in
open
Telemetry
is
not
a
suitable
name
anyway
and
given,
if
we
want
to
be
precise,
I
would
rather
remove
this
attribute
for
now,
at
all,
and
edit,
later
or
I
would
introduce
some
sort
of
a
forwarded,
namespace
that
allows
to
capture
other
properties
of
the
forwarded,
header
or
components
right.
C
A
C
C
C
C
So
I
can
do
a
little
bit
more
research
on
forwarded,
Beyond
HTTP
confirm
there
is
nothing
and
if
I
discover
this
I
can
go
ahead
and
send
APR
to
introduce
forward.4
right
and
specify
what's
in
there,
but
I.
Don't
think
we
need
to
Define
other
components
yet
because
we
can
always
add
them
later.
A
And
leave
HTTP
client
IP
alone
or
to
rename
that
remove.
A
C
A
Yeah
I'm
not
too
worried
at
least
I
mean
on
my
particular
use
case
or
reason
for
and
I
can't
find.
A
Yeah
but
that's
more
on
the
tracing
side,
yeah.
A
B
A
But
it
doesn't
match
Prometheus
world.
E
A
Yeah
and
so
seconds
both
of
these
actually
are
very
related
to
Prometheus
the
seconds.
Also
because
seconds
is
what
Prometheus
uses.
A
A
Making
HTTP
stable
I
feel
like
the
goal
of
making.
That
stable
is
that
we
can
then
release
stable
versions
of
our
HTTP
instrumentation
and
our
HTTP
instrumentation
does
produce
exceptions.
C
So
if
there
are
two
separate
concerns
right,
so
the
document
stability,
the
HTTP
semantic
conventions
document
the
status
experimental-
says
nothing
about
exceptions
right.
So
this
document
can
become
stable,
with
independent
layer
of
exceptions,
but
instrumentation
users
uses
both
so
instrumentation
cannot,
but
it
should
be
reasonably
fine
right.
A
D
Does
help
the
users
I
I,
like
the
is
there
much
in
the
way
of
needing
to
Market
stable,
like
the
exceptions
I
made
a
convention.
A
You
mean
much
contention.
D
A
Four
yeah
there's
four
attributes:
Josh
had.
A
Josh
added
a
couple
of
he
had
some
concerns
around
just
languages,
documenting
first
of
all,
Josh
sort
of
felt
that
exceptions
are
de
facto
conventions
or
de
facto
already
stable,
because
they're
referenced
by
the
SDK
specification.
A
You
know
what
is
documenting.
What
that
layout
is.
A
A
A
Which
we
still
could
do
we
just
couldn't
Mark
those
instrumentations
as
stable,
but
that's
yeah.
No,
that
I
I
can
see
that
that
still
has
a
lot
of
value
and
at
least
we're
on
the
Java
side.
We
get
hit
a
little
bit
because
the
spring
folks
get
annoyed
with
us
for
not
having
stable
artifacts
that
all
our
artifacts
are
still
Dash.
Alpha.
D
Yeah
yeah
they
so.
D
Yeah
they
have
their
own
kind
of
micrometer
names
and
things
like
that.
It's
yeah
it's
very
much
annoying
but
yeah
yeah
and
makes
sense.
D
I
wonder
how
much
work
would
it
be
to
resolve
this
exception
stuff
because
yeah?
Ideally,
it
is
just
resolved
because
you're
right
yeah
it's
hard
to
Mark
the
instrumentation
stable
without
this
being
stable,
even
though
it
feels
like
such
an
unimportant
part,
at
least
for
me,
but
it
probably
does
need
to
be
stable.
A
I
think
the
so
from
talking
through
it
sounds
like
at
least
we
should
bump
this
down
on
this
group's
priority
list.
A
There's
if
we
have
time
to
deal
with
that
later
at
some
point
towards
then
that's
great
but
yeah.
Let's
try
to
do
want
to
be
conscious
of
keeping
the
scope,
narrow.
D
A
Cool
awesome.
Well,
thank
you
that
I
think
this
will
make
for
a
very
Lively
spec
discussion
tomorrow
and
this
one
people
can't
Pawn
off
and
say
wait
till
the
ECS
decision
like
we
have
to
decide
this.
We
open
Telemetry
has
to
decide
this.
A
A
A
And
so
we've
kind
of
we
I
put
out
this
that
basically
from
discussing
with
folks
here
that
you
know
if
we're
going,
if
we
want
to
do
this
Otep,
but
we
want
to
do
this
alignment.
A
We
should
align
the
HTTP
conventions
before
marking
them
stable
and
so
lydmill
and
I
have
done
a
bunch
of
work
to
map
out
what
those
conversions,
how
about
what?
What
those
mappings
would
be,
what
changes
we'd
have
to
make,
but
obviously
would
break
the
world.