►
From YouTube: 2022-03-30 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Oh
that's
good.
I
was
just
asking
how
how
the
world
of
microsoft
is
going
at
the
moment.
A
Being
good,
you
know
it
was
a
stocks
price
going
off
again.
A
B
D
D
D
B
If
any
one's
got
something
for
the
agenda,
the
video
put
it
on.
There
was
one
thing
that
I
noticed
I'll
just
pop
it
on
there
now.
B
D
D
It's
the
the
other
ot
operational
transforms
yep.
B
Yeah,
so
it
looks.
B
I
just
noticed
that,
because
we
got
mentioned
in
that
issue,
bogdan
was
saying
that
he
thinks
that
there
should
be
a
build
tool
sig
and
he
he
mentioned
our
work
group
instrumentation
work
through,
and
he
mentioned
a
few
other
people
so
and
just
he's
just
asking
the
people
so
one
I'm
I'm
happy
to
put
my
hand
up
for
working
on
that
stuff,
because
I've
I've
actually
raised
the
pr
in
that
repo
before,
but
it
just
didn't
really
get
enough
attention
so
and
it's
regarded
it's
related
to
the
semantic
invention.
B
So
because
it's
great
the
the
table
generations
and
all
that
kind
of
thing,
so
yeah,
I'm
happy
to
to
kind
of
you
know
be
a
representative
from
this
group
in
that.
B
Just
the
build
tools,
kind
of
stuff
yeah,
so
I
I
don't
know
that's
that's
all.
I
have
to
say
just
kind
of
it's
just
kind
of
like
a
fyi.
I
guess.
D
A
So
is
this
build
tool
about
build,
build
tools
about
building
some
framework
to
verify
something
conventions,
or
is
it
or
something
something
more?
Whether.
B
The
build
tools,
build
tools,
is
a
repo
under
the
open
telemetry
like
organ
github,
and
it
basically
is
just
a
bunch
of
tools
that
are
related
to
the
spec.
So,
for
instance,
there's
like
a
there's
some
python
code
in
there
one
of
the
things
that
does
the
python
code
in
there
and
it
generates
the
semantic
convention,
like
tables
attributes
and
things
in
the
spec
from
the
yaml
files.
It
takes
the
young
files
and
it
generates
all
that
markdown
that
we
that
we
reference.
B
So
it's
still
in
like
early
stages,
because
obviously
semantic
mention
isn't
stable.
We
haven't
really
looked
at
the
metrics
demand
convention
at
all,
so
it
doesn't
really
do
much
with
regards
to
metrics
amanda
convention,
which
is
something
I
was
looking
at,
and
then
it
also
has
stuff
regarding
protobuf,
schemers
and
yeah.
That
kind
of
thing,
so
that's
just
basically
what
it
is.
A
Yeah
yeah
that
sounds
great
to
have
it
as
a
separate
stuff
and
going
forward.
We
might
also
like
a
as
a
part
of
that
sequel.
It
might
be
possible
to
look
into
this
framework
to
automatically
verify
if
some
specific
implementation
of
open
source
metric
or
some
specific
platform
follows
conventions
or
not.
B
Yeah
yeah,
like
a
testing
harness
kind
of
thing,
we've
talked
about
that
before,
haven't
we
yeah
yeah.
That
could
be
something
that
could
be
a
useful
thing
to
put
in
there
too
yeah.
D
Yeah
in
particular,
for
instrumentation
is
like
a
thing
we've
discussed
like
as
we
start
stabilizing
these
conventions
kind
of
like
the
next
step
is
to
go
update
all
the
instrumentation,
and
we
don't
really
have
any
kind
of
like
test
harness
for
instrumentation
in
any
way
or
any
like
helper
tools
for
instrumentation
authors
to
basically
make
their
life
easier.
There's.
B
D
D
Given
you
know,
there's
gonna
be
a
lot
of
instrumentation
out
there,
especially
in
like
the
future,
where,
like
open
source
authors,
like
library,
authors
start
thinking
about
like
pulling
open
telemetry
in
and
like
natively
instrumenting
their
stuff,
so
that
you
don't
need
to
install
a
plug-in.
B
I
feel
like
it
sounds
like
something
that
could
be
its
own
repo
or
it
could
be
particle,
build
tools.
D
B
D
I
think
it's
a
mix
of
like
language,
specific
stuff-
and
maybe
some
kind
of
you
know
yeah
some
kind
of
test
harness
that
helps.
You
check
whether
the
the
stuff
you're
emitting
is
is
correct.
C
I
actually
think
that
it
could
be
useful
before
like
to
make
to
help
us
make
decisions
like
the
hardness
right
and
without
it
like
it
made
it
change
a
while
back
that
we
wanted
to
have
some
attributes
available
before
something
right
for
something
and
the.
C
Was
okay?
We
were
not
sure
what
current
instrumentations
do
so
to
help
make
us
make
informed
decisions
and
require
things.
Such
hardness
would
be
extremely
useful.
I'm
not
sure
how
we
can
stabilize
something
without
first
testing
that
instrumentations
can
conform
to
it
yeah,
but
it
is
something
if
I
have
any
free
time.
I
will
be
happy
to
work
on.
D
I
don't
know
that
we
need
to
like
become
the
like
owners
of
all
of
that
stuff,
but,
but
probably
we
need
to
audit
like
who
else
is
gonna
audit
it,
and
it
seems
like
if
we
do
all
the
work
to
like
go
through
like
all
of
that
stuff
once
if
we
like,
lift
it
all
up
onto
something
that'll,
make
it
easier
one
easier
for
like
stuff
to
just
stay
up
to
date
automatically
because
it
uses
like
some
library.
D
Let's
say
that,
like
grabs,
the
http
object
and
just
like,
writes
all
the
correct
things
down
on
the
span
or
whatever,
then
that
would
be
great,
but
at
least
like
yeah,
a
test
harness
so
like
in
the
future.
At
least
we
can
just
if
we
make
a
change
to
like
the
spec.
You
you
just
you
just
have
like
a
dashboard
somewhere
where
you
can
look
up
like
what's
not
conforming
to
it.
Otherwise,
we're
just
setting
ourselves
up
third
audit,
so
probably
the
the
sooner
we
we
do
that.
D
I
created
a
new
board
kind
of
guessed
at
what
columns
we
would
want
here,
and
I
see
someone
started
to
go
in
and
and
add
a
couple
of
things,
but
I
was
wondering
if
one
one
thing,
maybe
if
we
have
time
on
this
call,
we
could
just
think
about
like
what
what
our
remaining
work
is
and
just
quickly
like,
create
some
issues
for
that.
So
we
can
just
get
the
board
populated.
A
A
When
it
comes
to
v2,
I
put
these
two
things:
basically
out
of
v1
about
spam
links
and
about
context
propagation,
basically
just
to
reduce
the
scope
of
v1
that
we
previously
had
yeah
and
to
the
done.
I
just
put
these
two
items
that
we
clarify:
okay,
so.
B
A
Can
we
can
go
through
the
this
that
app
that
we
discussed
several
months
ago
and
just
to
we
can
create
more
items
for
b2
just
to
figure
out
like
what?
What
is
the
wrong
thing
to
have.
A
Yeah,
just
just
by
also
wanted
to
clarify
what
will
be
the
remaining
work
for
v1,
basically
for
the
issue
that
we
have
right
now
open
and
for
the
proposal
that
led
me
abroad.
Maybe
we
can
discuss
it
first,
great.
D
Okay,
yeah,
let's,
let's
jump
on
to
to
that,
so
I
do
think
if
we
pulled
out
using
links
into
v2
and
like
context
propagation,
are
we
satisfied
with
like
what's
in
v1
for
http
as
far
as
like
retries
and
redirect
stuff?
Are
we
just
gonna
not
just
not
have
anything
that
addresses
that
for
now.
A
We
do
have
retrys
into
rx
already
emerged
there.
So,
basically,
we
are
clarifying
this,
that
for
each
retrial,
redirects
we're
going
to
create
a
physical
span
and
we're
also
going
to
add
this
additional
attribute.
Basically
that's
already
in
master,
and
this
is
a
part
of
the
specification
right
now.
So
that's
how
we
can
address
redress
in
the
directs
for
the
first
version
in
the
first
table
version
links
is
something
which
is
not
really
clarified.
A
Great
and
like
the
rest
of
this
pack
seems
fine
apart
from
the
the
attributes,
so
I
believe
once
we
clarify
them
all
this,
like
optional
versus
mandatory.
I
believe
we
can
just
start
the
process
announcing.
It
is
stable,
so
it's
probably
another
another
four
that
we
need
to
do.
I
have
no
idea
how
to
actually
make
it
how
to
announce
this
table
because
we
never
did
it.
D
Great
yeah,
I
think
announcing
it-
is
really
just
making
a
blog
post
but
again
like.
D
Nothing's
gonna,
nothing,
no
instrumentation.
We
have
conforms
to
the
new
stable
thing,
so
I
guess
that's
just
the
other
thing
to
think
about
like
do
we
want
to
do.
We
want
to
like
audit
everything
first
before
we
go
announcing
this
stuff
or
I
guess
we
could
make
an
announcement
and
just
let
everyone
know
we'll
be
migrating
everything
over,
but
that's
just
the
thing
to
think
about.
A
Yeah
that
makes
sense
I'm
trying
to
follow
up
with
the
changes
that
we
are
recently
did
to
the
specification
with
a.net
implementation
with
dotnet
teams.
So
I
had
to
have
pull
requests
for
the
net
instrumentation
like
http
instrumentation,
just
to
bring
this
http
right
right
into
directs
there
without
links
yeah
and
once.
C
Yeah,
like
so
sorry
to
jump
in,
I
recent
not
recently
a
while
back.
I
tried
to
go
through
all
the
issues
we
have
and
I
just
found
my
list.
There
are
a
couple
more,
I'm
pasting
them
to
the
chat.
They
are
related
to
specific
attributes
and
there
are
long
discussions-
and
I
don't
know
if
we
have
to
solve
it
right
now
and
maybe
just
categorize
whether
they
are
we
want
v1
or
v2
would
be
great
and
I
can
just
quickly
go
through
them.
If
you
don't
mind.
C
This
one,
okay,
so
the
the
one,
the
first
one
is
about
the
content
lens
attributes
which
are
not
clear.
Oh
I'm,
not
sharing,
sorry
think
there.
There
is
a
long
discussion
here
and
the
gist
of
it
that
those
attributes
are
not
clear.
They
are
high
cardinality.
You
cannot
use
them
on
metrics.
A
C
Perfect
yeah,
sorry,
okay,
so
those
the
request
plans,
they
probably
should
be
captured
as
metrics,
not
as
spam
attributes,
and
there
is
a
long
discussion
here
like
I
think,
if
we
categorize
those
as
a
very
very
optional
and
maybe
opt-in,
then
we
won't
have
this
problem
at
all.
C
So
to
my
like
the
best
thing
I
can
propose
if
it
boils
down
to
the
the
question
of
required
and
optional
attributes-
and
I
think
we
can
solve
it
once
we
get
to
proposal-
I
have
in
a
different
issue,
but
I
just
want
to
get
anyone's
opinion
on
how
critical
we
think
it
is.
Should
we
even
approach
issues
like.
D
D
But
if
I'm,
I
also,
I
think,
about
traces
more
like
not
just
like
statistics,
but
also
this
is
where
I
go
like
trace,
has
effectively
replaced
logs
for
me,
and
you
know
you,
you
end
up
wanting
to
put
your
logs
into
your
traces.
D
C
D
Yeah
they
could
be
logs
to
like
events,
but
like
is
there
an?
What's,
I'm
just
curious,
what
the
the
issue
is
with
having
them,
as
as
fan
attributes.
C
So
the
one
that
the
like,
if
you
want
to
build
anything,
for
example,
you
want
to
get
the
average
size
of
your
htcp
outgoing
call
right.
Those
are
sampled,
you
won't
be.
You
won't
even
be
able
to
query
for
it
properly.
This
will
be
an
estimation
right,
so
you
can
say.
Okay,
maybe
this
request
was
too
long
because
it
was
too
big,
but
I
mean
you
never
know
the
the
problem
with
uncompressed
things.
C
D
Right
yeah,
I
don't
know
it,
it
seems
valuable
as
a
metric,
but
it
also
seems
valuable
as
just
information
about
the
the
request.
C
B
Yeah,
I
suppose
I
suppose
the
idea
is
that
it's
hard
to
filter
by
when
you're,
because
I
guess
it's
just
so
high
cardinality,
it's
like
a
it's
an
amount
of
bytes.
So
it's
hard
to
filter
by
that
attribute,
I
guess,
is
the
point
against
it,
but
also
if
you're
looking
at
a
kind
of
span
just
individually,
it
might
be
useful
to
just
say.
Oh,
this
is
a
very
large
requested
response,
or
something
like
that.
So.
D
Yeah
yeah,
exactly
it's
not
I
mean
you
you,
you
can
use
a
histogram
and
and
bucket
these
things
really
easily
like
that's
that's
one
good
way.
If,
because
I
can
certainly
see
like
outliers
and
content
length
being
you
know
a
source
of
like
an
indicator,
something
is
horribly
wrong,
but
just
yeah.
The
other
side
of
spans
is
just
informational
right
like
something
blew
up
way
over
here
and
then
I
look
at
the
trace
and
notice.
D
There's
something
some
weird
input
or
some
aspect
of
something
seems
like
off
or
strange
to
me
as
like
an
operator
right
like
that's
like
like
a
pretty
common
part
of
investigating
issues
is
just
like,
as
an
operator
you
just
like
look
through
everything
that
happened
and
kind
of
like
look
for
stuff.
That
seems
like
it's
weird
and
so
nothing
noticing
that
something
has
like
a
content
length
of
zero
or
you
know
just
something
weird
might
be
helpful,
but.
C
Yeah
cool,
okay
and
the
other
one
I
want
to
bring
to
your
attention.
I
I
read
it,
but
I
completely
forgot
what
it
was
about,
but
that
the
essence
that
there
is
a
currently
a
target
which
represents
the
past
and
a
query
at
the
same
time
and
trust
suggests
to
split
them
right,
and
I
think
it
makes
a
lot
of
sense.
But
maybe
by
the
next
time
I
can
go
and
somebody
else.
D
And
so
is
it
the
case
that
target
means
two
different
things.
C
Parse,
you
have
to
parse
it
if
you
want
to
filter
by,
by
bypass
only.
D
Yeah,
which
I'm
recalling
is,
is
actually
the
reason
it
was
added
like
a
thing
that
came
up.
I
think
in
like
the
early
days
was
when
we
kind
of
did
our
first
pass
on
instrumentation
stuff
was.
There
was
like
a
feeling
like
we
wanted
instrumentation
to
avoid
over
head,
and
so
there
were
cases
where
you
don't
have
you
don't
have
this
information
parsed
target
is
like
essentially
what
you
have.
D
But
I
don't
I'm
not
personally
like
invested
in
that
argument,
and
I
don't
know
how
common
it
is,
but
I
think
that's
why
target
showed
up
to
begin
with,
for
what
it's
worth.
B
Yeah,
I
think
it's
probably
one
of
those
cases
again
where
we
have
some
kind
of
like
priority
of
like
if
you
have
access
to
the
path
and
the
query
then
use
it.
If
you
don't
then
use
target,
I
think
there's
something
that
like
that,
that
already
exists
right.
It
might
just
be
a
matter
of
clarifying
or
rearranging
it
in
some
way.
I
haven't
read
the
whole
thread
so
I'll.
Do
that
after
this
and
put
my
thoughts,
but
I
think
oh
that
makes
sense.
A
I
have
a
couple
of
thoughts
about
this
one
so
like
the
first
one
is.
Probably
targets
is
just
just
a
target:
it's
not
really
available
on
the
client
side,
because,
mostly
on
the
client
side,
we
just
have
a
like
a
url
which
represents
the
whole
thing.
It's
just
a
string.
A
Yep
so
yeah,
that's
purely
looks
like
it's
purely
about
server
and
when
it
comes
to
server,
do
we
have
path
and
query
separated
looks
like
we
do.
Have
this
pass
plus
query
as
a
as
a
data
available
all
the
time
so
actually
to
split
it,
we
need
to
parse
it.
C
What
what
trusk
is
saying
that
most
java
server
libraries?
They
have
them
separate
and
they
have.
A
I
see
that
that's
that's
actually
opposite
right.
Well,
yeah,
then
it
makes
sense
yeah,
and
the
second
thought
is
that
currently
or
yeah
we
will.
We
were
always
we
were
discussing
this
security
concerns
and
we
were
saying
that
target
can
potentially
or
target
or
url
can
potentially
contain
some
sensitive
information.
A
Now,
if
we
split
them,
we
need
to
say
that
both
of
them
can
contain
this
sensitive
information
since
pass
can
contain
some
user
ids
and
query
can
contain
some
tokens
or
even
passwords
or
whatnot.
So
it's
not
a
concern,
another
concern,
but
something
that
we
need
to
keep
in
mind.
If
you
want
to
split
them,
then
we
need
to
also
keep
in
mind
that
we
also
want
to
kind
of
mark
it
as
a
can
as
a
filled
potentially
containing
sensor.
Sensitive
information.
C
A
Yeah,
that's
the
thing,
because
pas
can
also
contain
some
some
data
right.
So,
for
example,
for
rest
urls
you
can
have
like
you
can
hear
clearly
have
some
user
ids
and
paths
like
update
user
one,
and
this
this
one
is
something
which
which
in
the
device
user
and
should
be
kind
of
redacted.
Okay,.
D
Yeah
for
what
it's
worth
target
is
defined,
but
you
know
I'm
it's
interesting.
I
can
see
that
christian's.
D
Is
that's
actually
like
clearer
and
better
for
everybody
at
least
that's
kind
of
the
impression
I'm
getting.
You
know.
C
I
can
only
agree.
I
think
that
the
question
is
what
is
easier
right
on
both
sides.
Sorry,
if
everyone
combines
pause
and
query
into
a
target,
then
probably
we
should
split
them
anyway.
So
exactly
yeah.
We,
let's
think
how
we
can
prioritize
it
by
the
next
time.
So
far
it
seems
like
it's
not
really
that
important
and
probably
we
can't
keep
target
well,
it's
important
because
target
is
required
attribute
and
if
we
change
it
it
will
be
breaking
so
we
probably
have
to
figure
it
out
before
stable.
D
Yeah
yeah,
even
if
we
decide
we
want
to
regularize
these
things
in
terms
of
like
a
priority,
then
you
know
we
should
define
that
priority.
You
know
for
sure.
D
I
I
threw
it
onto
the
board
as
a
v1
issue:
okay
yeah,
I
say
I
saw
it
already
yeah,
I
don't
know
I'm
I'm
tempted
to
say
that
we
should
split
it
into
path
and
query
and
and
say
that,
like
it's
worth
for
libraries
that
do
have
to
parse
this,
to
do
it
like
that,
it's
just
worth
the
overhead
of
doing
that.
D
Personally,
I
mean
there's
no
there's
no
perfect
solution
here,
but
it
kind
of
feels
like
the
more
optional
the
data
coming
out
of
open
telemetry
is
like
like
it
that
actually
just
makes
doing
something
useful
with
the
data
really
complicated
and
the
there's
this
been
this,
like
implicit
assumption
in
that
argument
that,
like
whoever
is
consuming
the
data,
is
like
some
giant
company,
that's
going
to
put
like
lots
of
people
and
resources
into
consuming
the
data.
Therefore,
it's
like
fine
that
consuming
open
telemetry
data
involves
just
a
giant
nest
of
switch
statements
and
garbage.
D
I'm
not
I'm
not
I'm
not
sure
that
I'm
sold
on
that
being
true
one,
I'm
not
sold
on
like
everybody,
putting
a
lot
of
effort
into
parsing
this
data
correctly.
You
know,
like
one
side
effect,
is
like
open:
telemetry
works
very
unevenly
in
different
back
ends
and
two
I'm
going
like
really
a
lot
more
sympathetic
to
the
idea
that
open
telemetry,
if
it's
very
regular,
would
be
good
for
people
who
want
to
do
novel
things
with
it.
D
We
we
make
life
really
hard
for
that
use
case
if,
if
the
data
isn't
regular
right,
like
like
statistical
analysis
and
big
data
systems
and
like
machine
learning
systems
like
really
suffer
when
the
more
irregular
the
data
is
like
the
worse,
those
tools
are
so
I
don't
know.
I
I
think,
there's
a
good
case
to
be
made
to
say,
like
actually
open.
Telemetry
should
be
providing
clean
and
regular
data
as
a
priority
over
like
small
performance
improvements.
C
Yeah
and
just
to
I
don't
know
how
to
agree
more
with
this.
The
the
next
topic
is
exactly
about
this
part.
C
Okay,
so
let
me
jump
into
the
optional
views
required
yeah,
so
I
think
there
are
multiple
things
here
and
the
first
one.
The
first
argument
I
I
made
is
that
let's
say
when
we
talk
about
client
right,
we
have
four
sets
of
attributes
that
people
can
set,
and
ideally
it
should
be
one
set.
C
And
if
you
look
closely,
for
example,
there
is
url
and
then
these
four
are
the
other.
Three
are
the
same:
it's
just
a
different
name
for
the
host
you're
calling
right
and
then
you
you
might
have
port
it's
optional,
because
if
it's
default,
one
right,
80
or
443
and
then
basically
the
only
thing
we
need
to
unify
is
the
this
part.
But
let's
get
there.
There
is
the
same
story
for
server
right.
We
have
multiple,
I'm
sorry,
okay
and
for
server
it's
the
same
story
rate.
C
So
it's
going
to
be
boring,
but
bear
with
me
so
the
url
available
on
all
clients
in
all
languages
right
so
for
server
servers,
usually
have
to
construct
it
from
fragments
right.
I've
done
it
for
dotnet
for
java,
for
gold
for
python
for
javascript
in
case
of
javascript,
everything
is
constructed,
so
nothing
helps
so.
The
first
proposal
I
want
to
make
is:
we
should
only
populate
http
url
on
clients.
C
We
don't
need
to
require
fragments,
they
can
be
optional
and
then
let's
talk
about
different,
optional
stuff
in
just
a
second,
but
we
can
be
relatively
sure
it's
possible,
because
if
it's
possible
in
five
languages
and
with
all
possible
java
and
python
instrumentations,
then
probably
it's
possible
everywhere
else
was
maybe
a
very
rare
exception.
C
The
second
part,
like
I,
also
checked
what
clients
populate
beyond
your
row
and
you
can
see
the
net
pair
attributes
are
pretty
rare.
They
they
sometimes
appear.
Sometimes
not
java
is
pretty
consistent.
They
have
port
and
name
go
populates
everything
everywhere
python.
It's
it's
very
inconsistent.
C
C
Okay.
Yes,
if
we
move
one
to
the
server
analysis,
it's
a
bit
more
interesting.
So
for
server.
We
have
three
different
ways
to
set
hofstra.
There
is
http
host,
which
is
the
host
header
according
to
specification,
but
actually
how
it's
populated,
sometimes
it's
host
header.
Sometimes
some
instrumentations
do
the
host
plus
port
right
and
yeah.
So
it's
it's
not
really
consistent.
There
is
also
net
host
name.
I
think
it's
it's
never
explained.
C
What
is
it
at
all
in
case
of
http
and
I
think
very,
very
few
instrumentations
actually
populated,
because
it's
it's
not
I'm
not
clear
what
and
there
is
a
server
name
which
is
actually
the
server
name
directly
from
nginx
or
apache,
and
there
is
a
virtual
host
name.
So
this
this
is
actually
clear
of
what
it
is,
but
the
way
it's
populated
again,
it's
very
rare.
So,
for
example,
in
javascript
it's
just
a
manual
configuration
you
can
override
it.
C
If
we
look
into
the
okay
gold
populates,
it
I'm
not
always
sure
how,
but
it
does
and
yeah
in
case
of
java,
the
out
of
I
don't
know
20
different
server
instrumentations,
just
one
of
them
actually
populates
it
dotnet
doesn't
so
I'm
trying
to
understand
I've
tried
to
understand
how
we
can
unify
these
three
things
into
one,
preferably
right,
and
then
we
will
not
have
a
question
about
the
the
actual
the
set
of
attributes.
C
So
I
think
what
we
can
leverage
is
this
name.
We
can
be
more
specific
what
it
means
we
can
say
there
is
a
priority
if
you
have
the
virtual
host
name,
the
server
name
directly
for
something
it's
the
first
priority.
It
can
go
here.
If
you
don't
have
it,
then
host
header
can
go
there
and
okay,
if
you
have
a
manual,
maybe
it's
priority,
minus
one
that
overwrites
everything,
but
basically
we
can
say
there
is
one
required
header.
C
This
is
the
priority
list
and
this
is
the
best
available
server
name,
the
instrumentation
can't
figure
out
and
regarding
url
on
servers
servers
as
I
mentioned,
either
constructed,
or
they
don't
populate
it
at
all.
For
example,
java
doesn't
populate
url.
There
are
some
other
cases
when
url
is
not
populated,
go,
doesn't
python
populates
and
javascript
populates
it
so,
but
if
we
can
say
that
majority
of
the
servers
provide
this
one
set
of
parts
of
euro,
then
that
the
url
becomes
not
necessary
and
it's
an
extra
performance
here
to
actually
populate
it
for
servers.
C
With
this
in
mind,
I
have
a
proposal
yeah.
So
there
is
another
consideration
for
us
brought
up
that
okay
url
is
great,
but
for
metrics
we
would
need
peer
attributes.
So
the
url
is
hype.
Cardinality,
the
peer
name
is
not,
and
port
is
not,
and
then
with
those
two
we
can
build
metrics
per
endpoint
right.
C
Okay,
so
then
those
three
should
become
required
and
if
we
talk
about
server,
then
those
four
with
a
special
semantics
for
net
host
name,
which
explains
the
priority.
C
The
route
is
very
important
for
server
instrumentation
and
we
currently
call
it
optional
optional
in
a
sense
that
we
don't
know
if
it's
available,
but
what
I
want
to
propose
is
when
we
say
required,
we
should
mean
required
to
populate
when
available.
So
if
you
have
it
by
all
means,
you
should
populate
it
right.
So
route
is
important
for
metrics
and
it's
a
like
to
query
things
for
it.
I
want
this,
this
method
of
this
controller,
to
to
filter
by
your
group
by
yeah
right.
C
B
I
agree
route
is
the
probably
the
most
useful
one
for
a
server
is
what
about
http
method?
Is
that
that's
part
of
your
proposal.
B
D
By
the
way,
thank
you
so
much
for
doing
this
audit
and
review,
and
this
also
makes
me
think
it
would
be
really
nice
if
we
had
some
kind
of
test
artist
that
just
like
posted
this
information
somewhere.
So
yeah.
D
Ever
again,
right,
but
just
actually
one
question
was
around
the
peer
stuff.
You
mentioned
keeping
it
around
on
the
client
for
metrics,
but
are
those
metrics
that
could
just
be
emitted
on
the
server
side
like
like?
Do
we
need
to
emit
those
on
the
client
side.
C
Cool
cool,
then
I
think
the
next
step
would
be
to
I
really
want
to
get
dc
member
sponsorship
on
this
change
right.
This
is
the
process
we
follow
now.
D
C
C
C
So
you
can
see
that
they
are
not
required,
but
somewhere
in
the
spec.
It
says
that
requiring
explicit
configurations
for
headers
to
be
captured.
So
as
the
next
step,
if
we
get
through
the
one
set
of
attributes,
I
want
to
have
this
clarification
instead
of
the
required
flag,
so
that
some.
C
And,
for
example,
host
header
can
be
logged,
sorry
can
be
put
in
this
sorry,
the
request,
header
field.
It
doesn't
need
to
be
a
separate
attribute
right,
because
now
we
have
a
conflict
right.
We
have
two
different
ways
to
log
this
header
and
then
was
this
split
in
three
categories
right,
so
the
general
approach.
I
want
three
categories:
there
are
required
attributes
that
we
should
always
provide
and
we
believe
every
instrumentation
should
provide
them.
C
Some
rare
instrumentations
can't,
but
still
it's
required
if
you
have
it
so
this
like
two
categories
in
one
and
then
the
optional
attributes.
Oh
sorry,
this
is
not
the
last
latest
version
of
things,
culture,
I'm
sorry
yeah.
So
so
this
two
are
merged
in
one.
C
And
then
there
are
two
other
things,
so
things
may
be
like
user
agent.
You
should,
you
should
provide
it,
and
most
of
the
instrumentation
should
provide
it.
Some
particular
users
are
not
interested
in
it.
They
can
opt
out
of
them.
We
don't
specify
how
right
we
it's
it's
the
future
possibility,
but
then
there
are
and
instrumentations
doesn't
have
to
provide
this
configuration
right
away,
and
then
there
are
opt-in
like
headers,
that
you
don't
provide,
but
some
users
who
want
maybe
specific
headers
or
specific
attributes
they
can
again.
D
Yeah,
that
makes
a
lot
of
sense
to
me.
We're
gonna
have
to
come
up
with
a
configuration
language,
but.
E
D
C
Cool
then
that's
all
I
had
about
it.
My
steps
are
to
talk
to
rayleigh
and
figure
out
how
to
get
his
sponsorship,
and
if
it
goes
well,
then
the
build
tools
will
be
the
next
step
to
working
it.
A
Yeah,
it's
really
awesome,
but
like
do
we
know
how
much
time
it
can
take
to
figure
out
all
this
stuff,
even
with
riley,
and
even
if
he
get
his
sponsorship
here
like
it
might
take
some
time
for
us
to
go
through
it
and
actually
affect
the
date.
When
we
can
make
the
specs
table.
A
D
You
know,
get
get
this
proposal
to
like
the
pr
stage
right
as
quick
as
we
can
with
with
riley
and
then
bring
it
up
in
the
main
spec
meeting
and
put
it
on
slack
and
stuff
like
that
and
and
then
just
try
to
aggressively
resolve
whatever
conversations
come
up.
You
know
just
just
just
basically
kind
of
ping
keep
pinging
people,
but
also
have
a.
D
You
know
if
we
don't
get
much
feedback
where
the
feedback
gets
resolved,
then
you
know
we
can
close
it.
You
know
after
like
say
like
a
week,
so
I
think
that's
that's
the
main
thing
to
do
and
why
I
think,
having
tc
sponsor
like
riley
is
helpful
is
what
we
need
is
a
way.
D
We
need
some
kind
of
tiebreaker
right,
like
hopefully
everyone
just
like
thumbs
up
everything
or
makes
like
a
really
important
point
that
everyone
agrees
with
and
we
change
it,
but
for
the
where
we
get
stuck
is
when
some
people
think
it
should
be
one
way
and
some
people
think
it
should
be
the
other
way
and
like
that's
that,
that's
where
we
need,
I
think,
like
a
tc
member
to
just
just
call
it
right
like
we
have
to
pick
one.
D
If
we
can't
all
agree,
then
you
know
it's
the
spec
maintainers.
To
my
mind,
the
spec
maintainers
are
the
people
who
are
stuck
picking
in
those
situations
right
because
I
don't
know
who
else
gets
to
pick,
but
that's
usually
where
these
things
seem
to
get
jammed
up
right
now
is
on
that
step.
So
as
long
as
we
have
like
tc
member
willing
to
be
like
well
we're
just
going
to
go
this
way
with
this
one.
Sorry.
C
D
A
D
Also,
it
won't
be
ready
in
april,
I
don't
think,
but
I
have
proposed
creating
like
a
spec
backlog
like
a
project
board
for
spec
work
kind
of
like
focused
on
this,
like
all
this
stuff,
the
community
should
be
focusing
on
for
that
month
to
like
resolve
one
way
or
the
other
and
get
done
having
like
a
project
board
that
we
go
over
in
the
spec
meeting
and
that
the
the
tc
in
the
spec
community,
like
you,
know,
triages
it
at
every
spec
meeting
and
like
once
a
month
figures
out
what
the
the
sprint
for
the
next
month
should
be
something
along
those
lines.
D
D
Spec
sprint,
you
know,
is
like
resolve
this,
like
http
optional
stuff,
and
that
would
help
anyone
who
wants
to
have
a
say
in
it
knows
like
this.
Is
your
opportunity
to
have
a
say
in
it
and
then
we're
gonna
chip
it
and
I've
gotten
an
engineering
manager
from
lightstep
who's
interested
in
being
like
the
to
like
tpm
the
project
board,
basically,
so
so,
hopefully,
that
that
will
help
this
stuff
going
forwards,
but
we're
we'll
we'll
have
to
do
without
it.
A
Sounds
great
to
me
yeah
at
least
we
can.
We
can
try
it
too
and
if
it
works,
it
will
be
great
for
us
to
just
make
things
going.
If
not
we
can.
We
can
do
something
else,
but
definitely
we
need
to
try
it
like
to
push
as
hard
as
possible
and,
like
last
time,
we
discussed
that
we're
going
to
finalize
all
the
work
by
by
end
of
the
end
of
march.
So
now
it's
on
the
4th.
A
What
our
next,
what
our
next
date,
that's
the
question.
Yeah.
B
D
So
I
mean
we
finalized
the
scope
of
work.
Right
like
this
is
this?
Is
it
nothing
else
is
going
into
v1
right
so,
but
in
terms
of
like,
when
do
we
think
this
stuff
will
be
closed?
A
Yeah
because,
like
you
know
the
sooner
or
the
the
more
we
postpone
it,
it
actually
affects
all
the
other
stuff
yeah.
So
all
the
libraries
can
can
do
they
plan
and,
for
example,
when
it
comes
to
some
implementations
like
a
hearing.net
world,
they
also
are
really
concerned
about
what
is
happening
in
spec
and
really
wait
for
it
to
be
at
somehow
stable
before
even
do
some
planning
about
it.
Okay,
so.
D
Well,
hopefully,
we
can
get
this
stuff
committed
to
the
spec
in
two
weeks.
I
think
it's
that's,
maybe
a
good
goal
for
us
to
have
and
to
tell
riley
about,
but
yeah
it's
it's.
I
feel
like.
I
guess
it's
like
hard
for
me
to
like
make
a
guarantee
right,
like
that,
that's
kind
of
why
I
want
to
get
something
like
a
sprint
board
going,
because
it's
like
hard
to
say
what
it
means
to
to
make
a
promise
like
that
makes
sense.
D
I've
been
burned
too
many
times
at
the
open
telemetry,
where
I
make
that
commitment,
and
then
people
who
are
not
me
but
are
required
to
be
part
of
the
process,
make
it
not
happen.
So.
D
I've
I've
yeah
I've
become
like
scotty
from
star
trek.
Where
you
know
I
just
like
quadruple
my
estimate
when
I
give
it
to
people
so
that
at
least
I
don't
look
like
an
idiot
when
it's
late.
A
So
maybe
we
can
just
yeah,
as
I
mentioned.
Maybe
we
can
try
to
push
it
more
during
the
spec
meeting.
Yes,
that's
one
is
8.
A
D
So
there's
the
optional
versus
required
right,
there's
like
target
versus
like
path
and
query
right
like
it
seems
like
that,
can
get
folded
into
this
pr
and
then
and
then
there's
like
the
content
length,
headers.
C
Yeah
yeah,
I
I
can
try.
You
know
what
it
reminds
me
that
I'm
not
sure
how
much
the
politics
you
follow,
but
the
recent
russian
laws
against
fakes
were
part
of
some
forest
protection
package
just
to
speed
it
up.
You,
you
use
some
other
trading
to
ship
stuff,
okay,
I'll,
try
right.
A
Well,
content
land
actually
definitely
falls
into
this
bucket,
so
we
can
just
say
it
like
a
opt-in
and
that
that
might
be
it
when
it
comes
to
passenger
person.
Query,
that's
might
be,
it
might
be
tough
just
because,
basically,
we
are
like
a
break
in
what
what
we
have
right
now
and
but
yeah.
That's
that's
probably
can
be
discussed
as
a
part
of
the
same
topic
right.