►
From YouTube: 2023-02-07 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
No
worries
Dennis,
said
he'll,
be
here
in
in
a
second.
B
B
So
I
think
you
know.
Ecs
alignment
is
a
great
thing
to
strive
for,
but
I
don't
want
that
to
block
us
and
I
want
to
have
an
alternate
path.
You
know
lined
up
and
if
we
can
start
going
down
this
path
anyway
and
if
that
makes
it
easier
to
align
with
ECS
later,
that's
a
bonus.
B
So
the
things
so
I
think
that
the
most
you,
the
thing
that
I
think
we
at
least
Riley
and
Ludmilla-
have
chatted
with
felt
like
had
the
most
potential
positive
impact
was
the
scoping
things
under
URL
from
a
reuse
perspective
across
other
semantic
conventions.
C
Yeah
one
one
question
I
had
here
about
like
these
renamings
is
mostly
about
the
topic
that
we
also
like
attached
a
bits
last
time
and
about
the
like
a
namespaces
or
you
know
just
defining
Scopes.
So
when
we're
talking
HTTP,
specifically
like
a
HTTP
submitting
conventions,
do
we
want
all
of
them
to
have
this
kind
of
namespace
kind
of
HTTP
dot,
something
or
it
those
are
like
I'm,
not
really
to
Independent
things
like
all
of
like
everything
that
we
treat
as
HTTP
should
not
be
necessary,
defined
under
HTTP
Dot.
C
C
Yeah
I
know
we
already
have
some
some
net
dot
attributes
here,
but
those
are
mostly
kind
of
just
the
references
to
something
else.
Right.
B
C
Got
it
so
basically,
the
whole
approach
here
will
be
just
to
kind
of
have
different
groups
of
attributes
which
are
Independence
and
can
be
reused
across
signals
potentially
and.
C
Yeah,
in
this
case,
it's
not
really
clear
what
exactly
http
means
right,
because
if
we
want
this
cross-references,
it
basically
means
that
all
the
things
that
we
are
referencing
should
be
also
defined
as
table
like
we
discussed
last
time,
and
since
that
all
these
kind
of
all
those
shared
attributes,
there
is
no
kind
of
scope
or
whatever
like
it.
It
probably
will
be
not
really
a
straightforward,
how
we
want
to
Define
them
stable
right,
so
I.
C
C
C
It
will
be
really
helpful
if
they
can
kind
of
understand
that
HTTP
is
basically
a
superset
of
other
semantic
conventions
like
just
by
grouping
different
groups
of
attributes
together
and
those
are
also
kind
of
stable.
B
So,
do
you
think
that
it's
I
mean
the
way
I
see?
That
is
this
document
defines
stability
like
everything
in
this
document
is
what
is
HTTP
semantic
conventions
and.
C
C
That's
that's
the
question
like
if
we
want
to
put
like
a
stability
status
for
the
whole
documents,
which
it
basically
means
that
everything
that
they
put
here
cannot
be
changed
right.
Yeah,
that's
nice
version,
but
if
you
have
these
cross
references-
and
we
also
need
to
kind
of
make
sure
that
all
these
things
that
we
are
referencing
from
here
will
not
be
changed.
B
Which
I
think
is
lud
Miller's
point
about
the
yeah,
the
attribute
in
the
attributes
as
stable,
somehow
and
then,
but
you
were
also
mentioning
from
a
user
perspective.
If
they
come
did
they
want
to
see
how
to
implement
HTTP
semantic
conventions?
B
That's
sort
of
what
I
thought
the
eight
the
markdown
was
for
is
to
then
pull
everything
into
one
place.
So
they
just
have
this
one
dot
one
to
look
through
and
they
don't
really
need
to
go
off
into
the
net
stuff
or
the
URL
stuff.
C
A
B
So
the
next
kind
of
grouping
I
was
looking
at
was
you
know?
Do
we
want
to
group
things
under
like
for
HTTP
requests
and
HTTP
response
delayed?
This
is
what
ECS
is
doing.
Http,
request
method.
It
should
be
response
status
code,
HTTP,
request,
dot,
contentlength
response,
dot,
content
links.
A
A
No
I
mean
except
method
and
the
user
agent.
There
is
nothing
that
can
be
even
put
into
request.
C
A
A
B
Don't
have
any
objections?
No
no
I'm,
just
I
didn't
quite
follow
what
you
what
you
were
saying
about.
No
other
changes,
no
other
renames.
B
Sold
there's
also,
potentially
in
the
future,
like
body
request,
body
content,
response
body
content
Which
is
popular
though
people
don't
like
it
I
don't
want
to
add
it.
A
Do
you
want
to
identify
all
of
those
I
just
don't
see
any
any
problem
with
separating
requests
and
response,
namespaces.
C
B
C
Reasonable,
but
in
the
same
time,
it
brings
a
lot
of
like
a
breaking
changes,
I
mean
to
the
current
experimental
stuff.
So
the
only
one
thing
which
which
which
which
still
kind
of
I
feel
nervous
about
it
is
the
fact
that
even
experimental
as
many
conventions
are
already
implemented
in
a
lot
of
libraries,
instrumentation,
libraries
right
and
people
right,
we
can
like.
We
can
go
and
just
let's
say.
C
Them
with
the
break-in
changes,
but
I'm
also
I'm
also
concerned
about
users
which
already
use
in
Microsoft.
You
know
a
lot
of
you
know
other
teams
already
onboarded
to
all
this
stuff.
They
already
use
like
a
libraries
and
also
we
as
a
platform,
for
example,
like
my
team
as
a
distributed
racing
platform.
C
We
also
already
have
all
this
data
right,
this
old
kind
of
demanding
convention.
So
it's
from
this
perspective,
it's
a
really
breaking
change
and
when
I
was
talking
about
long
tail
last
time,
I
was
also
considering
these
two
parts
right
so
instrument
date
like
a
specification
instrumentation
just
a
part
of
the
picture,
but
all
other
things
are
still
there.
A
C
A
Like
the
choice
here
is
that
we
break
with
providing
some
Bridge
now,
there's
the
benefit
potential
benefit
of
getting
ECS
schema
supported
reasonably
world
right.
We
will
never
have
this
opportunity
again.
A
Yeah
so
like
we
can
like
what
Josh
suggested
that
we
will
provide
some
polyfill,
like
the
the
bridge,
maybe
duplication
for
for
a
while,
where
this
Kiba
translation
should
be
there,
but
given
how
frequently
we
modify
semantic
conventions,
everyone
who
uses
experimental
ones
is
already
in
the
place
where
they
have
to
support
it
and
everything
breaks
all
the
time.
A
C
I
mean
there's
no
way
around.
That
makes
sense.
Yeah
this
polyfill
thing
is,
is
still
something
that
we
just
need
to
keep
in
mind
as
an
action
item
when
we
do
all
this
through
the
headings.
B
B
A
The
body
is
HTTP
terminology
right,
so
I
think
there
is
that
the
content
lens
had
the
problem.
We
already
have
it
optional.
We
are
headers
and
here
this
content
plans
can
be
mixed
with
the
headers
content
plans
and
then
content
lands
as
a
header
is
a
tricky
one,
because
sometimes
you
don't
have
it
right
so,
but
you
might
know
it
after
you
read
it
and
sometimes
you
can
populate,
even
if
Heather
is
missing
so
I
kind
of
like
the
body
thing
better,
because
it
creates
this
level
of
abstraction
right.
B
Yeah
that
makes
sense
to
me
any
initial
thoughts
on
these
two.
A
So
for
Route
it's
an
interesting,
so
it
can
be
a
request,
but
also
remember
we
discussed
that
it's
it's
actually
not
the
initiative.
We
think
it's
like
a
rather
framework
thing,
so
it
can
be
http.
C
B
B
So
we've
got
kind
of
the
full
ECS
thing
option:
we've
got
the
our
net
option,
but
I'm
not
really
sure
if
forwarded
IP
is
not
clear
to
me
how
that
applies
to
network,
but
probably
just
because
I
don't
understand
low
level.
Network.
B
Short
of
moving
to
ECS
do
I
kind
of
liked
forwarded
IP
versus
client
IP,
but
this
is
is
more,
maybe
generalized.
This
is
kind
of
just
very
specific
to
the
http
thing
which
I
don't
know.
C
B
All
right
and
user
agent-
oh
yeah,
so
potentially
it
could
be
under
request,
scope.
B
Yeah
do
do
either
you
have
thoughts
on
user
agent
being
of
generalizing
to
again
kind
of
proactively
versus
outside
of
the
ECS
decision.
A
I
would
love
it.
We
have
a
full
request
for
up
Cosmos
folks,
they're
trying
to
add
their
semantic
convention
and
they
have
user
agent
and
Carlos
ask
them
if
they
can
generalize
it.
So
it's
already
there.
B
A
B
A
C
A
C
B
Okay,
there
were
two
things
on
the
board
that
I
wanted
to
one
was
this
grpc
HTTP
I
thought
we
could
remove
it
from
our
this
one
from
our
board.
I,
don't
see
anything
really,
it's
really
asking
for
changes
to
grpc,
nothing.
C
Yeah,
so
it
is
mostly
about
how
to
like
a
link
to
different
layers
right
if
you
have
grpc
communication,
it's
better
to
have
this
like
a
similar
statuses
from
like
a
coming
from
both
instrumentations
but
I.
Think
yeah.
It
has
nothing
like
there
is
nothing
to
do
for
HTTP.
It
should
be
just
moved
to
like
RPC,
so
many
conventions
and
specifically
geographies.
B
A
Was
looking
into
the
for
this
request
and
I
didn't
see
any
and
there
are,
there
is
some
original
discussion
linked
and
this
person
disappeared.
Yeah.
B
C
B
Cool
this
was
super.
Helpful
I
will
put
together
a
kind
of
a
couple
of
concrete
proposals
here
around
what
we
discussed
and
Float
them
to
you.
B
Maybe
today,
hopefully
today
before
the
so,
you
can
weigh
in
before
the
spec
meeting.
But
it's
not
like
anything
that
I
presented.
The
spec
meeting
has
to
be
what
we
it's
like
official,
it's
more
I,
just
I'm,
trying
to
stir
the
pot
a
little
bit
like
trying
to
get
people
to
pay
attention
to
us
and
and
weigh
in
with
their
thoughts.
A
So
do
you
like:
do
you
want
to
present
like
different
sites
like
various
for
improvement,
regardless
of
ECS,
and
what
can
we,
how
close
we
can
get
to
ACS
is
correct.
Yeah.
B
What
I
want
to
present
tomorrow
is
sort
of
some
potential
recommendation.
Some
things
that
we
want
to
think
about.
You
know
put
PRS
in
place
to
do
regardless
of
the
ECS
decision.
A
B
You
know
hey,
these
are
there's
compelling
reasons
to
do
X,
Y
and
Z.
Even
if
we
don't
go
to
ECS
and
hey,
it
also
potentially
gets
us
closer
to
ECS
trying
to
not
get
us
blocked
on
the
ECS
decision.
B
Yeah,
this
completely
ignores,
of
course,
all
the
network
level
stuff.
Yes,
quiet
server,
Source
destination,
yes
yeah,
which
yeah
we
need
Alex's
help
with.
So,
yes,
I'm
I
like
to
start
with
the
the
easier
things
yep.