►
From YouTube: 2022-05-04 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).
A
C
B
B
Martin,
can
you
summarize
yesterday's
discussion
for
the
sake
of
those
that
were
not
there
yesterday.
A
So
I
think
we
we
talked
about
yesterday.
We
talked
about
kind
of
the
overall
state
where
we
are
right
now
we
have
been
working
on
three
different
old
taps.
A
A
I
think
some
toys
has
been
working
on
that,
I
believe
that's
ready
as
well
or
close
to
ready
and
the
last
one
is
the
discussions
we've
been
having
last
few
weeks
about
sessions
and
specifically
where
to
where
how
to
represent
session
ids
where
and
how
to
send
them
over
the
wire.
A
So
I
think
that's
the
last
piece
for
us
to
figure
out,
and
that
would
be
a
third
potentially
a
third
otep
if
we
decide
that
it
belongs
on
the
resource
and
we
had
discussions
last
week
with
tigran
and
bogdan,
and
but
we
have
not
made
a
final
decision
decision
like
we
know
that
we
know
some
of
some.
A
We
know
like
some
of
the
edge
cases
or
some
of
the
complications
with
with
sending
with
sending
as
a
resource
attribute,
but
we
have
not
settled
on
a
final
solution
yet
so,
once
once
we
made
make
this
decision,
we
can.
We
can,
you
know
open
these
three
old
apps.
B
Is
there
a
way
we
can
get
started
once
the
let's
say
the
logs
or
tip
is
accepted?
You
know
we
could
start.
You
know
the
work
except
for
sessions.
So
do
you
think
that's
a
good
idea,
considering
that
you
know
we
could
keep
all
of
this
as
experimental,
anyways
and
and
then
once
the
sessions
part
is
also
included.
B
You
know
we
could
mark
it,
as
you
know,
ready
for
further
use
and
and
given
that
sessions
is
anyway
an
optional
feature.
It's
something
that's
an
opt-in,
as
in
somebody
has
to
you
know
when,
when
building
the
initial
instrumentation
integrating
the
application,
you
had
to
explicitly
include
sessions
aspect,
although
I
I
agree
that
it
will
have
to
be
part
of
the
base
packages
without
needing
to
separately,
it
won't
be
any
extension
or
a
plugin.
It
will
be
part
of
the
base
packages,
except
that
it
will
come
towards
the
end.
C
Yeah
or
just
just
roll
with
the
the
resource
provider
prototype
that
santosh
is
working
on
like
as
far
as
our
prototypes
are
concerned,
we
could
just
continue
to
use
that
until
we
get
told
definitively
that
you
know
we're
going
to
do
something
else,
so
I
would
suggest
just
just
rolling
with
that.
For
the
time
being,
I
don't
think
it
should
block
any
of
the
other
work
we're
doing.
D
Yeah,
I
I
second
that
I
I
think
we
should
start
how
we
wish
to
continue,
rather
than
if
we
put
it
in
the
in
the
envelope.
In
the
event,
we're
never
gonna
get
it
out
and
we'll
you
know
we'll
get
pushback.
Why
do
we
need
this
resource
provider
thing
if
you've
already
got
it
there?
So.
B
Yeah
one
challenge
I
see
with
that
approach
is
that
you
know
our
changes
won't
be
merged
on
on
main
and
and
therefore
people
will
have
to
use
packages.
You
know
locally
built.
C
C
You
know
to
get
our
prototype
merged
into
js
and
stuff
like
that.
Actually.
B
The
reason
I'm
expecting
the
resource
you
know
being
mutable,
you
know
for
that
aspect
to
take
a
long
time
is
because
I
get
a
feeling
that
it's
not
just
a
matter
of
respect,
but
also
you
know
it
will
also
involve
identifying
and
making
changes
to
the
existing
behavior.
Where
you
know,
people
will
have
to
consider
moving
attributes
that
they
today
consider
as
part
of
the
identifying
attributes.
But
then
you
know
with
this
change,
you
know
they'll
have
to
move
it
out
and
vice
versa.
C
I
think
it'll
only
take
a
lot
of
time
if
you
can't
get
people
to
pay
attention
to
it.
Essentially
I
I
do
have.
I
agree
with
you
that
there's
one
big
open
question
for
me,
which
is
is
it?
C
Is
it
real
that
that
that
there
are
back
ends
which
rely
on
this
resource
fingerprinting
mechanism?
If
that's,
how
people
read
the
spec
and
that's
something
that's
widely
implemented,
where
people
are
just
taking
a
hash
of
the
whole
resources
and
not
looking
at
what's
in
them,
and
therefore
adding
these
updatable
ones
really
is
screwing
them
up,
then
I
think
we
might
have
a
problem
if
there
are
only
a
handful
of
back
ends
that
operate
directly
on
open
telemetry
data.
You
know
yeah.
B
C
Yeah,
it's
not
I
when
I
think
about
backwards
compatibility
there.
I
think
that
it's
a
solvable
issue
to
go
to
go
inquire,
whether
something's,
really
gonna
be
a
problem,
and
I
I
have
a
lot
of
faith
that
that
isn't
the
case
and-
and
we
can
just
introduce
a
concept
of
like
marking,
resources
is
either
updatable
or
permanent.
C
This
could
be
my
proposal
permanent
meaning,
if
you're
going
to
put
this
resource
here
at
all,
it
has
to
be
there
from
the
beginning.
So
you
can't
not
put
cloud
provider
and
then
later
tack
on
cloud
provider
like,
even
if
you
you
ca,
it's
not
just
that
you
can't
change
the
value
of
it.
Is
that
it's
either
there
or
it's
it's
not
there,
and
for
like
a
variety
of
projects,
now
we're
starting
to
want
something
like
a
a
validator
plug-in
for
the
collector.
C
C
Maybe
if
we
can
get
to
that
point
of
being
able
to
propose
like
permanent
versus
updatable
resources,
we
can
provide
safety
mechanism
there,
along
with
how
we're
going
to
provide
it
for
kind
of
like
the
rest
of
our
semantic
conventions,
which
is
to
to
use
this
collector
validator
as
like
something
in
development,
or
you
know
in
your
ci
cd
pipeline
when
you're
doing
smoke,
testing
or
whatever
you
you
pipe
it
through
this
plug-in,
and
it
warns
you
whether
or
not
you
are
emitting
incorrect
or
invalid
data
of
any
kind,
and
that
would
include
having
permanent
resources
mutating
or
being
flaky,
or
something
like
that,
so
that
I,
if
we
don't
hear
back
from
like
splunk
and
new
relic,
or
you
know
some
other
or
jaeger
and
they're
like
you're,
going
to
totally
like
screw
a
pipeline
up.
C
If
you
do
that,
if
that
doesn't
happen,
I
think
I
think
we're
good.
C
If
it
does
happen,
then
I
would
suggest
we
add
another
top
level
thing
that
is
essentially
resources,
literally
just
another
key
value
set
right
in
like
the
right
next
to
resources
that
we
call
enrichments
or
or
some
other
nonsense
where
we
can
put
these
things
that
that
would
be.
That
would
be
my
backup
suggestion.
I
don't,
I
think
that
adds
more
complexity
than
adding
nuance
to
to
resources,
but
but
to
my
mind,
it's
it's
one
or
the
other.
C
Having
done
all
this
review,
I'm
very
firmly
convinced
we
should
not
be
mixing
these
global
identifi.
These
global
attributes,
in
with
like
span
context
and
scope
context,
like
all
the
other
places
we've
been
proposing
to
to
jam
them
in.
I
just
think
that's.
This
stuff
is
like
too
important
to
just
be
do
doing
stuff
like
that.
It's
like
semantically
incorrect
to
to
mix
this
stuff
in
with
these
other
contexts,.
D
Yeah,
so
the
only
based
on
the
meetings
I've
been
attending,
the
only
references
I
heard
from
hashing
I
thought
it
was
headers
was
aws,
so
I
I
don't
know
if
they're
doing
something
there
too,
and
I
thought
that
was
in
the
context
of
validating
that
the
package
wasn't
changed
in
the
process.
C
That
that
might
be
a
separate
issue.
They
they
had
an
issue
with
spam,
ids
changing
from
request
to
request
because
they
have
like
a
signed
header
concept
for
all
of
their
all,
like
aws
code,
basically
creates
a
signature,
that's
like
a
like
a
hash
of
all
their
headers
and
we
include
like
span
id
and
headers.
So
if
you,
if
you
change
that
span
id
when
you're
retrying
the
request,
then
it
like
breaks
their
it
breaks
their
signature
thing
that
that
might
be
what
you're
you're
thinking.
D
Yeah
yeah
that
sounds
like
it
that
way,
it's
just
so
that's
just
the
transport
level,
not
a
backend
level.
I
can't
think
why
you
would
want
to
effectively
hash
all
the
resources
and
keep
them
grouped
that
way
unless
you're
effectively
recreating
the
session
id
based
on
that.
C
We
don't
include
a
reliable
instance.
Id
a
clever
rabbit
could
decide.
Well,
that's
fine,
I'll
I'll,
just
use
this
like
fingerprinting.
D
A
So
so
do
you
think
we
can?
We
should
somehow
try
to
get
this
information
by
bringing
it
up
in
the
specifications
sig
or
is
it
just
enough
like
to
open
the
otap
and
wait
for
feedback.
C
Yeah,
let's,
let's
do
both
let's,
I
think
we
should
go
ahead
with
this
resource
provider.
Otep,
like
we've,
been
getting
some
attention
from
like
bogdan
and
tigrin.
Let's,
let's
just
widen
that
by
by
pushing
forward
with
that
as
a
as
an
otep,
okay
and
just
yeah,
we'll
we'll
either
get
shot
down
or
accept
it,
but
if
it
gets
shot
down,
I
think
it'll
transmute
in
the
process
into
yeah.
I
think
we'll
get
ideas
for
more
people.
D
Yeah,
I
think
that's
what
tigran's
doing
with
his
instrumentation
okay
scopo
tip
now
right,
it's
just
putting
it
out
there
and
pushing
it
through.
I
I
think
it's
a
a
very
similar
correlation
between
all
three
concepts.
B
B
Yeah,
I
I
am
I'm
working
on
the
logs
api
hotep,
I'm
I'm.
I
still
need
like
another
three
four
days
to
you
know
finish
it.
I
have
a
first
cut,
which
I'm
going
to
get
reviewed
by
tigran
and
jack
in
the
lockstick
today
and
based
on
that
I'll,
you
know,
wrap
it
up
and
submit
the
whole
tip
in
a
few
days
after
which
you
know
I'm,
I
can
you
know,
work
on
this
resource
provider
tip.
B
I.
I
also
want
to
go
over
all
the
previous
tickets
on
this
topic.
I
have
like
some
six
or
seven
tickets.
I
I
want
to
understand
them.
Surely
you
know
at
least
so
far.
I
could
find
only
the
situation
where
it
is
still
the
identifying
attributes,
but
they
are
available
later
and
that's
why
they
they
want
the
ability
to
update
the
resource
at
a
later
time
after
it's
created,
but
it
is
still
identifying
attributes.
B
So
I
I
want
to
understand.
You
know
what
the
other
tickets
say,
other
issues
saying
and
and
I'll
put
them
in
one
document.
B
About
the
like,
it's
not
the
first
time
that
this
topic
has
come
up.
It
looks
like
for
the
last
two
years.
Different
people
have
been
bringing
it
up.
It's
just
that
for
us,
it
is
turning
out
to
be
fundamental,
but
whereas,
in
other
cases,.
C
Yeah,
I
I
would
suggest
we
actually
just
because
I'm
familiar
with
those,
what
we
want
to
do
is
is
clarify
that
what
we're
talking
about
is
actually
not
the
same
thing
and
that
we
aren't
proposing,
in
fact,
that
we
want
to
include
language
around
like
permanent
attributes
to
to
to
make
it
clear
that
when
we
add
this
feature,
you're
you're,
not
this
isn't
like
opening
the
door
to
allowing
people
to
to
do
this
late,
late,
binding
thing
yeah.
C
D
Yeah,
I
think
if
we
maybe
phrase
it
so
that
the
resource
provider
effectively
it's
a
bit
like
the
context,
it's
immutable
once
it's
in
there,
but
you
know
you
can
actually
have
a
different
one
from
you
know
which
you
can
inherit
from
a
different
root
or
something
like
that.
C
We
we
mark
whether
the
resources
we've
defined
in
the
spec
are
permanent
or
not
or
updatable,
or
not
like
make
it
super
clear
that
you
can
now
update
session
id
and
user
id,
but
you
can't
you
can't
it's
it's
illegal
to
to
use
this
mechanism
on
session
instance
id
or
something
like
that.
C
Yeah
or
or
a
validator
would
be
my.
D
C
A
A
So
I
think,
beyond
after
this,
we
can
start
working
on
the
semantic
conventions.
Santosh
and
I
had
started
talking
about
it,
so
we
can
perhaps
next
week.
One
of
the
topics
can
also
be
starting
to
look
at
semantic
conventions
for
some
some
events.
B
As
as
an
attribute
at
the
scope
level
to
distinguish
events
coming
from
the
client
side
versus
the
logs
from
it
coming
from
the
client
side,
let's
say
tomorrow,
you
know
your
ios
or
android
app.
You
know
it
also
is
emitting
logs
that
that
need
to
be
pushed
out,
but
they
are
different
from
the
events.
B
B
So
if
that
goes
through
in
the
documentation,
it
might
be
confusing
to
some
people
in
the
future.
So,
but,
but
I
I
wanted
to
find
out-
maybe
you
know
we
can
formally
use
it
as
well
like
we
have
been
looking
for
some
ways
to
distinguish,
even
let's
say
all
type
of
telemetry.
B
You
know
distinguish
from
client
side
to
the
you
know
the
back
end
telemetry
so
and
and
this
could
be
again
at
the
resource
level-
I
I
just
wanted
to
get
some
feedback
on
on
this
attribute
called
hotel.clientside
equal
to
true
right.
I
think
this
topic.
B
I
think
we
have
spent
a
lot
of
time
in
the
beginning,
but
you
know
we
have
not
had
success
and
I
think
we
have
stopped
talking
about
it
in
the
last
couple
months,
but
I
think
if
you
remember
martin,
we
were
told
that
boolean
attributes
are
not
so
common,
but
I
I
think
for
for
the
browser
and
the
mobile
at
least
for
the
browser
we
were
able
to
identify.
You
know
any
attribute,
starting
with
browser.
Namespace
is
a
client
set
right
for
the
foot
for
the
mobile.
B
You
know,
given
that
the
mobile
could
be
any
other
device
as
well
like
iot
devices
or
your
even
your.
You
know,
laptops
desktop
applications,
so
I
wanted,
I
initially
suggested
using
the
device
as
the
name
space
device
dot.
Anything
is
is
coming
from.
B
You
know
that
where
the
term
device
is
very
popular
right
and-
and
there
could
be-
you
know
your
temperature
monitoring
on
on
your
servers-
they
might
use
the
term
device
as
well,
so
we
haven't
been
able
to
narrow
down
the
you
know,
a
convention
to
distinguish
client-side
telemetry,
so
so
now
that
tigran
is
using
this
hotel
dot
set
equal
to
true.
A
So
I
just
wanted
to
remind
that
there
is
there's
an
issue
open
for
this.
A
There's
been
a
little
there's
been
a
little
bit
of
discussion,
but
not
much
so
I
think
if
you
have
opinion,
take
a
look
at
this
issue.
There
is
a
few
different
options
for
proposed
for
classifying
the
client-side
telemetry
and
yeah.
We
haven't
made
a
final
final
decision
it's
for
for
browser.
A
A
I
also
wanted
to
remind
like,
if
you
have
any
opinions
about
this
now,
is
the
time
to
take
a
look
and-
and
you
know,
comment
otherwise-
it's
probably
gonna
get
merged.
Like
this
week.
I
haven't
marked
any
of
those
attributes
on
browser
as
mandatory,
so
I
right
now
the
way
it's
written.
I
don't
think
they
could
be
used
as
to
classify
browser
instrumentation.
A
So
my
my
my
thinking
was
like,
if
you,
if
you
can't,
if,
like
the
user
agent,
cannot
determine
if
there's
no
api,
there's
for
some
reason,
no
no
way
to
get
the
information
about
the
user
agent,
then
it
should
not
be
required
to
add
those
attributes.
A
A
It's
already
in
the
specification
right
now,
the
for
for
for
mobile
devices.
Like
I,
I
agree
that
it's
not
clear
if
device,
you
know
what
kind
of
devices
that
that
namespace
could
be
used
to
represent
one
of
the
proposals.
One
of
the
comments
in
that
issue
was,
to
maybe
add,
like
a
an
attribute
like
a
device
kind
where
you
could
specify
that
it's
a
mobile
or
you
know,
iot
or
something
like
that.
C
I
don't
as
an
alternative
approach.
There
is
like
an
os
type
field
that
we
could
potentially
switch
on.
I
guess
that's
not
really
exactly
telling
you
whether
it's
a
mobile
device
or
not
you're,
just
kind
of
assuming
if
it's
running
android
or
ios,
it's
a
mobile
device,
but
that
would
be
a
another
way
of
doing
it.
D
Yeah,
just
circling
back
to
like
identifying
whether
it's
coming
from
client
side
or
not.
I
I
guess
I've
got
two
general
thoughts
on
this.
So
in
terms
of
the
events
that
we're
adding
here,
I
I
think
we
just
we
don't
care.
The
event
name
identifies
the
type
of
event
it
is,
and
those
types
are
either
unique
to
client-side
or
they're.
Not
you
know,
a
client
should
still
be
able
to
send
some
form
of
generic
event
in
in
terms
of
logs
and
spans.
D
F
The
forking
of
client
telemetry
yeah,
I
believe.
F
Yeah,
I
believe
it
is
the
event
name.
The
client
type
might
not
be
there.
B
Yeah,
I
think
the
the
concern
with
event
name
using
the
event
name
is
you
you
want
to
have
some
at
least
a
common
name
space
so
that
you
know
for
every
new
event
that
you
add
you
know
you
don't
have
to
update
that
condition,
and
it's
it's
a
it's
a
hierarchy
right.
I
think
you
can
always
check
every
individual
event
name
or
you
check
the
prefix
of
the
event.
E
B
Or
even
better,
you
check
the
presence
of
an
attribute
attribute
name,
not
the
attribute
value
and,
and,
and
you
know
even
better
could
be
like
you
check
the
presence
of
a
prefix
of
the
attribute
name.
So
it's
a
you
know.
Each
of
them
offer
different
level
of
performance
at
the
time
of
decision,
so
yeah.
D
A
Do
you
think
we
should
have
for
if,
if
we
define
types
of
events
such
as
interaction
or
exception
error,
those
should
be
like
two
different
name
spaces
for
one
for
mobile
and
one
for
browser,
it
could
be
yeah.
D
Potentially
yeah,
it
depends
in
the
case
of
exceptions.
D
We
don't
because
effectively
there's
a
common
set
of
things
with
an
exception,
like
you
know
the
message:
the
stack
trace,
the
line
number
et
cetera
so
yeah.
It
really
is
case.
Once
we
get
this
collection
of
events,
we
can
then
look
at
them
and
then
say:
okay,
we
want
to
effectively
have
this
as
a
generic
event
versus
isolated
for
web.
F
Yeah,
so
the
I
think
we
need
to
kind
of
talk
about
the
common
schema
concept.
You
know
it's.
Basically,
the
semantic
dimensions
for
internal
events
and
stuff
azure
monitor
does
not
use
it.
So
we
have
this
hierarchy,
like
you
know,
sometimes
referring
to
that
and
then
you
know
we
were
kind
of
really
do.
F
For
this
example.
Browser
services,
client.
We
do
have
a
base
class
so
to
speak,
that
defines,
let's
say,
page
views
and
clicks
and
exceptions
at
the
top
level.
It
could
be
called
client
dot,
page
view,
that's
it.
So
we
don't
know
what
client
it
is
and
then
for
browsers.
We
have
an
inheritance
that
that
gen,
that
creates
a
page
view
event
for
the
web
that
derives
from
that
thing.
So
if
you
examine,
I
think
it
ends
up
being
on
the
event.
F
It
ends
up
being
a
property
that
you
examine
it's
what
type
it
is
the
base
class
or
something.
I
think
it
is
that
the
type
is
required.
You
know,
we've
been
talking
about
it,
so
we
need
to
have
know
what
client
type
it
is.
You
know
if
we
don't
have
that
inheritance
hierarchy
in
in
our
semantic
conventions.
We
need
to
have
a
over
the
wire
at
rest.
The
event
needs
to
have
a
type
that
identifies
whether
it's
a
browser
or
iot,
or
anything
like
that
mobile
device
or
something.
D
Which,
I
guess
comes
back
to
the
flag,
so
if
we
were
to
effectively
have
something
like
that,
then,
rather
than
defining
as
true
false,
if
we
defined
it
as
a
set
of
values
based
on
santosh,
saying
that
boolean
types
weren't
strictly
supported
or
thought
bullying
types
were
strictly
supported
in
that
definition.
Earlier.
F
I
think
that
also
allows
us
to
you
know
if
there's
a
few,
you
know
in
future,
there's
a
different,
different
client
type
that
we
want
to
support.
You
know
that
you
know
would
be
a
good
good
way
to
go.
Otherwise
you
know
would
be
locking
us
into
whatever.
D
I
agree
yeah,
so
I
I
guess
extending
that
if
we
said
proposal,
hotel,
dot,
client
type.
B
Yeah,
I
think
yeah,
I'm
okay
with
that
too.
Just
to
type,
I
think,
that's
what
ted
suggested
right
device.type
would
that
be
equivalent.
A
E
B
B
So,
martin,
I
think
you
you,
you
are
driving
all
of
the
semantic
conventions
right.
So
maybe
you
put
this
starts
in
one
document
and
and
then
we
could
all
just
decide
something.
B
Something
and
I'll
share
it
with
group
yeah.
I
did
not
follow.
The
second
comment
in
the
chat
hundred
percent
are
what
what
does
that
say?
Is
it
that
the
client-side
telemetry
could
always
be
pointed
to
a
different
injection
point?
You
know
which
then
the
back-end
could
then
add
the
identifying
information.
E
Yeah,
so
my
too
long
didn't
read
would
be
that
if,
when
you're
accepting
data
from
the
public
browsers
applications
or
anything,
they
could
literally
show
something.
After
anything
and
like
if
you
mix
the
data,
you
can
send
data
that
doesn't
say
that
it's
from
the
browser
also
completely
easy.
So
I
would
rather
have
that
be
something
that
is
like
from
the
whatever
accepts
the
data,
be
it
interest
or
collector,
and
it
actually
marks
that
it
knows
that
it's
really
trusted
data
or
something
that
is
known
from
all
of
the
universe
comes
in.
B
Actually,
that's
a
good
point,
so
this
is
not
going
to
be
authenticated
on
all
the
client-side
telemetry,
so
yeah.
I
think
that
might
that's
a
good
point.
You
know.
D
Yeah
this
has
come
up
before
and
in
microsoft
we
don't
have
this.
We
have
the
single
common
endpoint,
but
it
doesn't
preclude
this,
like
you
can
change
our
sdks
to
send
to
your
own
back
end
for
any
form
of
authentication
and
from
there.
You
can
then
pass
it
on
to
to
our
backend
so
yeah.
I
think
this
is
more
of
an
implementation
thing.
We're
just
saying
your
exporter
sends
it
to
wherever
you
want
to
go.
C
I
think
we
still
need
to
figure
out
the
identifying
characteristics
at
the
semantic
level,
because
you
may
end
up
in
a
case
where
this
data
is
all
mixed
together
right.
So
we
should,
we
should
figure,
you
know,
figure
out
a
reliable
way
to
do
it
right
down
in
the
spec
hey.
C
This
is
what
we're
gonna
all
gonna
do
to
identify
something
coming
from
a
browser
or
something
coming
from
a
mobile
client,
something
coming
from
a
mobile
browser,
just
so
everyone's
clear,
and
we
can
then
go
like
ensure
that
we're
actually
producing
that
data
correctly
or
there
isn't
it's
not
expensive
to
do
that.
But
but
I
agree
with
the
other
comment
that
we
do
you.
You
can
use
something
like
a
gateway
to
to
just
fork
off
the
data.
C
You
still
won't
be
able
to
tell
whether
it's
a
mobile
device
or
a
browser
without
checking
the
data,
but
but
just
as
an
aside,
I've
been
talking
to
some
people
from
shopify
recently
and
and
they're
they're
interested
in
joining
the
sig
hello.
C
If
there's
anyone
who
happens
to
be
here
from
shopify
and
one
of
the
things
they
were
interested
in
exploring
is
authentication
or
just
to
to
what
degree
it's
feasible
to
to
to
do
some
form
of
rotating
credentials
or
something
that
just
make
it
harder
for
for
people
to
to
use
this
as
yet
another
ddos
endpoint.
D
I
guess
you
know
having
come
from
the
identity
space,
it
really
comes
down
to
the
the
thing.
That's
doing
the
the
the
socket
connection,
the
transport.
That's
the
point
that
with
the
authentication
happens
that
has
to
happen,
and
it
would
be
either.
D
You
know
a
a
token
included
with
the
payload
or
a
cookie
that
is
authenticating,
that
particular
user.
So
yeah,
it's
it's
not
specific
to
rum
itself.
That's
I,
I
think
the
transport
layer
aspect
here.
We
would
definitely
need
an
api
on
top
to
define
how
that
would
be
allocated
like
for
azure
monitor.
We
have
a
set
authenticated
user,
but
that's
not
used
for
authenticating
the
the
connection
that's
used
for
companies
to
identify
who
the
user
is
in
a
in
an
authenticated
manner,
so
they
they
can
then
determine
unauthenticated
versus
authenticated
traffic.
B
Actually
nev,
I
think
the
question
my
understanding
is.
The
question
is
more
about:
how
do
you
like
all
these
security
controls?
You
know
they
require
that
you
rotate
the
keys
right.
They
rotate
the
token.
D
D
B
B
Yeah
but
but
then
in
a
in
a
browser
application,
at
least
you
know
it's
in
your
control,
you
change
the
key
and
then
you
know
in
a
few
days.
Hopefully
you
know
everybody
will
refresh
will
go
to
a
new
page.
You
know
they'll
get
the
new
keyway,
but
with
mobile
application,
especially
android.
The
the.
C
G
C
D
Where
you
have
your
back
end
effectively,
you
use
your
your
basic
authentication
so
you're
effectively,
let
the
user
sign
in
and
only
once
they're
signed
in.
You
start
accepting
telemetry
from
them,
but
that
has
the
disadvantage
that
well
you're,
not
getting
any
telemetry
because
they're
not
signed
in.
So
it's
it's
a
catch-22.
B
Yeah
yeah,
there
is
no,
you
know
good
solution
for
this
problem.
I
think
yeah.
F
For
client-side
authentication
has
come
up
a
lot
of
times,
and
you
know
it's
essentially
a
non-starter
the
moment
you
throw
authentication,
then
you
lose
all
of
the
anatomy
of
traffic,
which
is
the
biggest
section
of
the
traffic
we
want
to
capture
yeah.
Somebody
is
having
issues
signing
in.
I
want
to
know
if
I'm
not
getting
telemetry
from
them,
I'm
basically
flying
blind
until
everything
just
works.
Fine.
So
it's
a
non-starter
yeah.
H
I
think
part
is
just
about
increasing.
You
know,
friction
right.
The
cost
of
someone
running
like
chrome,
headless
versus
being
able
to
make
a
direct
request
from
like
a
ddos
standpoint
I
mean
is
a,
I
guess
at
least
significant
scale
wise,
but
it's
but
yeah.
Obviously
anything
that's
client-side
is
still
going
to
be
limited
away.
If
you're
going
to
let
like
anonymous
traffic,
send
telemetry.
H
C
Yeah,
you
probably
want
to
solve
this
more
with
things
like
throttles,
like
per
connection
throttles,
maybe
like
a
big
giant,
kill
switch
that
turns
off
the
acceptance
of
unauthenticated
traffic.
You
know
just
some
some
mitigations
you
can
use.
F
Exactly
typically,
that's
prevention
is
what
we
rely
on.
Nem
said
for
application
insights,
the
azure
monitor
thing.
You
know
both
server
traffic
and
client
traffic
go
to
the
same
endpoint,
so
they
do
have
big
ddos
prevention
mechanisms
and
they
also
have
authentication,
enabled
injection,
but
that's
not
enforced
at
the
at
the
injection
key
level.
You
can
say
I'm
only
going
to
accept
authenticated
traffic.
F
That
means
I
don't
have
client
traffic
at
all,
so
I'm
isolated
and
they
have
good
good
enough
starting
mechanisms
to
prevent
you
know
the
server
from
taking
my
ikey
down
when
somebody
else
has
got
to
open
another
traffic
coming
through
in
the
internal
windows
side.
It's
also
the
same.
The
windows
telemetry
everything
that
comes
from
your
machine,
the
computers,
those
are
all
authenticated,
but
anything
browser
is
an
authenticated.
They
all
go
to
the
same
endpoint.
They
rely
on
ddos
prevention,
that's
it
and
we
get
garbage
all
the
time.
C
C
You
know
and
add
in
some
features
like
this,
like
throttling
authentication,
the
you
know
or
the
ability
to
to
to
kill
them.
C
That's
just
sending
us
garbage
all
the
time,
and
so
like
most,
I
think
fender
back
ends
have
effectively
hardened
themselves
against
ddos
attacks,
even
without
thinking
about
it
in
terms
of
like
bdos,
but
more
about
like
don't
let
this
customer
do
cost
overruns
or
like
just
don't.
Let
our
own
tool
knock
our
system
over
because
someone
screwed
up
somewhere,
but
I
I
don't.
I
don't
totally
know
to
what
degree
the
solutions
we've
gone
with
are
like
the
same
solutions
that
say
a
a
smaller
team
at
an
individual
company.
C
That's
running
like
their
own
observability
tool.
You
know
where
they
they
have
essentially
like,
like
a
five-person
team
working
on
the
problem,
I'm
curious
like
what
what
kind
of
basic
stuff
open
telemetry
could
could
bake
into
its
pipeline.
That
would
help
help
those
teams-
you
know,
have
some
basic
tooling
around
this
stuff,
because
I
don't
think
we
can
ask
them
to
to
go
hard
in
their
their
whole
pipeline.
The
same
way
that
you
know
a
100-person
team
can
could
think
about
standing
up.
H
Yeah
for
rosa
shopify
like
it,
it
might
be
somewhere.
You
know
in
between,
but
yeah
there's
gonna
be
a
lot
of
smaller
companies
that
don't
have
you
know
the
time
and
resources,
for
you
know
the
same
approaches.
A
We've
got
few
few
minutes
left
just
wanna
quickly.
Just
summarize
our
discussion
and
next
steps
so
we're
working
on
finishing
the
otec
drafts,
I
I
can
help
with
santosh.
If
anyone
is
interested
in
helping
with
this,
let
me
know
or
santosh,
we'll
also
start
working
on
semantic
conventions,
so
we're
planning
to
start
the
draft
document
and
bring
it
to
the
next
meeting.
A
Also,
if
you're
interested
in
this
work
ahead
of
time,
let
me
know
there's
that
classification
issue
open,
like
we
talked
about
that
today,
if
you,
if
you
have
opinions
about
this
comment
on
that
issue,
and
then
lastly,
there's
the
browser
attributes
pr
also,
if
you
have,
if
you
want
to
see
any
changes
to
the
pr
comment,
comment
on
that
now.
F
F
Yeah,
I'm
having
a
tough
time
typing
in
chats,
I'm
just
going
to
say
that
I
would
love
to
participate
in
the
semantic
conventions
thing.
So
just
sign
me
up
I'll
watch
it
for
stuff,
but
I'll
be
interested
in
part
of
that.
Okay,.
A
Yeah
all
right,
I
I'll
start
that
draft
document
and
our
circuit
circulated.
A
Okay,
cool
any
last
minute,
thanks
thanks,
everyone.
H
B
Okay,
I
I
can
make
an
attempt
one
minute
right,
so
so
I
in,
in
short,
I
think
the
we
have
agreed
on
using
the
logs
apis,
I
mean
logs
to
represent
the
client-side
events,
so
the
spans
will
remain,
but
for
the
rest
of
the
events
that
occur
outside
of
spans.
You
know
we
have
decided
on
using
logs
to
represent
them
and
the
logs
api
is
is
currently
in
progress.
B
It
will
be
ready
soon,
the
other
fundamental
piece
you
know
we
want
to
have
is
sessions
and
there
are
some
blockers
there.
We
want
to
keep
the
session
id
at
a
top
level
common
to
all
the
spans
and
events,
and
today
there
is
no
place
for
it.
So
that's
you
know
an
open
issue.
Right
now
and
third,
we
started
work
on
the
semantic
conventions
for
different
events
once
that
is
ready.
I
think
we
are
ready
to
submit
these
individual
tips
and
an
overall
rum
proposal
as
a
no
tip.
H
Gotcha
and
his
events,
how
we're
sending
like
metrics,
like
you
know
as
far
as
performance
and
things.
B
Like
that
we
talked
about
it
so
metric
there
are.
There
are
some
data,
like
I
think,
which
might
qualify
as
send
as
metric
instruments.
B
D
Yeah,
it
probably
depends
on
what
you're
measuring
like
if
you're
a
client
app,
and
you
want
to
measure
memory
usage.
Then
maybe
you
want
to
do
that
as
a
metric,
but
for
clicks
and
stuff
that
gets
just
going
to
be
events,
it's
really
going
to
be
up
to
how
you
want
to
do
it
and
what
you're
measuring.
H
Yeah,
I
think
the
thing
you
know
for
us
would
be
some
of
the
the
classic
rum
things
you
know
like
first
contentful
paint,
you
know
navigation
times
like
soft
and
hard
navigation.
That
kind
of
thing
yeah
interesting,
so
the
the
back
end
layer
is
going
to
be
heavier
there
to
actually
interpret
those
and
convert
those
to
metrics.
I
imagine
so.
B
That
you
need
anyways,
I
think
there
are
going
to
be
like.
Let's
say
you
want
to
compute
the
average
response
time
of
a
particular
api
call,
so
you
would
be
looking
at
the
spans
from
multiple
when
you
will
be
looking
at
multiple
spans,
and
then
you
know
deriving
that
metric
out
of
that.
So
you
will
need
a
a
framework
on
the
back
end
to
convert
events
and
logs
and
spans
into
metrics.
F
And
and
and
to
add
to
that,
even
if
you
had
a
metric,
you
know
that
is
defined
for
client-side
calculation
of
these
kind
of
things
you
still
have
to
aggregate
them
in
the
back
end
anyways,
which
is.
B
Okay,
actually
it
at
least
eliminates
there
there
might
be
the
metric
aggregation
stack,
will
already
be
there.
So
there
is
some
logic
in
sending
them
as
metric
instruments
so
that
there
is
so
you
have
the
infrastructure
to
aggregate
metric
instruments
into
metrics.
So
there
is
some
sense
in
sending
them
as
metric
instruments,
but
you
know
you
have
the
other
side
as
well,
where
you
need
the
events
as
well.
B
A
B
B
Yep,
I
don't
know
if
it
is
common,
but
the
the
collector
so
far
I
have
always
looked
at.
You
know
something
that's
deployed
at
the
customer
site,
not
on
on
your.
B
C
Yeah,
I
I
mean
again,
this
is
a
like
vendor
versus
small
shop
issue.
Potentially
like,
though,
for
the
record
like
at
lightstep,
we
we
run
the
collector
as
like
the
first
layer
of
our
ingestion
pipeline
if
for
no
other
reason
than
to
get
out
from
under
having
to
make
paint
a
whole
bunch
of
different
like
receiver
code
ourselves,
but
at
any
rate
there's
a
place.
We
we
do
provide
a
tool
if
you
want
to
stick
something
in
your
pipeline
somewhere
to
to
do
this.
C
But
but
I
agree
with
centos
that
most
part
of
the
problem
is
the
dimensionality
of
these
metrics
right
is
probably
going
to
be
something
you're
defining
through
creating
dashboards
and
things
like
that
and
the
the
client
can't
know
the
all
the
dimensions
that
you
want
to
scope
a
metric
by.
So
it's
better
for
you
to
just
store
all
these
things
as
events,
anyways,
okay,.
B
Okay,
actually
andy,
we
haven't
made
a
decision
on
that.
So
I
think
when
we
are
going
to
list
the
different
types
of
events
that
we
are
we're
going
to
generate
from
from
these
client-side
agents,
so
I
think
in
that
document
we
we
can
talk
about
this
again.
Where,
for
some
events
you
know
it
might
make
sense
to
send
them
us
metric
instruments
so
yeah,
we
will
revisit
that.