►
From YouTube: 2021-11-03 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).
D
E
C
Sure
that
was
this
one
was
it
by
me,
so
I
can
share
my
screen
in
a
second.
F
Okay,
so
this
this
pr
is,
is
about
bringing
https
to
the
initial
state,
and
I
did
some
changes
here
based
on
our
previous
discussions
and
the
like
a
timeline
that
we
discussed
last
time.
F
So
just
just
that's,
basically
the
heads
up
for
the
changes
I
did
and
to
probably
ask
you
guys
to
bring
some
more
attention
to
it.
So,
like
a
4b1
for
the
for
the
first
stable
version
we
have,
we
do
have
here
some
like
some
action
night
or
some
some
open
questions
or
scenarios
that
we
want
to
cover
and
this
pr.
Actually,
this
pr
captures
us
like
a
road
map
for
we
want
and
the
scope
for
v1
as
well
as
next
action
items
like
a
4b
next.
F
So
all
the
all.
The
points
that
I
have
here
is
something
we
definitely
or
a
subject
subject
for
discussion.
F
So,
that's
why
I
would
ask
you
to
give
your
feedback
here,
but
for
the
v1
I
posted
four
items
here,
so
the
first
is
is
about
like
a
required
attribute
success,
so
there
was
a
conversation
that
it
might
be
beneficial
to
have
like
to
specify
which
exact
attributes
should
be
specified,
as
required
ones,
for
example
for
http
client
it
can
be
just
url
and
for
the
http
server
it
can
be
these
three,
but
something
that's
it's
better
to
be
clarified.
F
Another
item
is
retries
and
redirects
is
something
that
I
am
currently
working
on,
and
I
also
have
pr
open
for
this
another.
Another
item
that
we
do
have
here
is
somehow
related
to
it
right
and
redirects,
and
it's
about
like
a
context,
propagation
like
how
it's
possible
to
propagate
some
items
between
calls
or
clean
up
contacts
before
making
a
call-
and
the
fourth
item
here
in
scope
is
security.
F
Concerns
is
all
the
stuff
related
to
sensitive
information
that
we
are
capturing,
for
example,
in
in
http,
url
sphere,
request,
url,
all
other
things
that
I
posted
previously.
I
moved
to
the
scope
for
we
next
and
we
do
have
a
lot
of
different
scenarios.
That's
probably
should
be
covered
as
well,
but
for
the
next
version.
F
So
that's
the
changes
and
we
also
have
something
that
we
have
totally
out
of
scope
here.
So
that's
the
current
eltab
and
I
would
be
appreciated
if
you
guys
can
bring
it
more
attention.
F
F
It
can
be
a
big
item
and
a
controversial
one,
since
we
do
have
these
open
questions
like
a
general
general
questions,
and
this
is
one
of
them.
So
that's
why
I
put
it
to
be
next,
just
because
it
can,
it
doesn't
look
like
it
can
be
achievable
for
the
next
several
months.
E
I'm
I
might
suggest
splitting
it
I
think,
figuring
out.
How
do
we
configure
stuff
seems
like
something
we
have
to
put
a
lot
of
thought
into,
but
it
does
seem
like
in
general,
people
don't
like
400s,
counting
as
errors,
so
you
might
want
to
consider
just
going
ahead
and
and
changing
the
default
there.
E
No
just
just
like.
Let's
just
change
the
default
and
then
play
in
in
the
future,
we
can
have
a
conversation
about
how
to
how
to
adjust
it.
In
the
meantime,
the
answer
is
just
use
a
collector,
like
it's
very
easy
to
use
the
collector
to
to
change
status
codes
on
on
things
based
on
whatever
you
want.
F
Okay,
yeah,
I
can
add
one
more
action
item
here
or
like
a
one
item
here,
just
particular
about
this.
Just
changing
the
defaults
so
like
I
just
exclude
before
for
x,
from
arabs,
because.
F
E
D
Default
for
spam
status
was
it's
not
an
error
if
it's
a
forex,
if
you're
on
the
server
side,
I
think
isn't
that
what
the
spec
specification
says
if
you're
a
client
and
you
get
a
4xx,
then
it's
an
error.
But
if
you're
a
server
and
you
get
a
4xx,
then
it's
a
it's
like
a
onset
or
something
like
that.
E
B
A
G
In
the
url,
as
well
containing
personal
information,
for
example,
jira
jira
tickets,
confluence
pages,
all
of
them
we
identify,
as
you
know,
customer
information
and
therefore
we
ask
our
developers
to
normalize
their
targets.
Normalize
the
urls
in
telemetry,
so
raw
urls
are
bad.
F
Yep
so
yeah,
basically,
that's
that's
something
that
we
haven't
scoped
here.
This
hotel
does
not
have
any
proposals,
how
it's
possible
like
how
exactly
it
should
be
done,
but
it's
it's
justifying
the
scope
and
this
this
this
item
is
in
scope.
So
if
you
yeah
just
if
you
want
to
solve
it,
then
it
looks
like
we
do.
We
do
want
to
solve
it
as
soon
as
possible
for
the
week.
E
E
F
That's
great
yeah,
so,
but
don't
you
mind
to
put
this
comment
to
the
to
the
pr,
so
it
will
be
tracked
and
can
bring
more
attention
to
it
as
well.
Sure
sorry,
which
comment
that
we
should
I
mean
I
mean
to
change
the
default
just
to
include
yeah,
like
include
this
item
in
scope
about
the
error
default.
E
A
D
And
you
have
a
pr
for
retries
and
redirects
as
well.
I
saw.
D
I
have
a
kind
of
proposal
about,
or
maybe
just
a
question
about
what
people
think
about
this
in
terms
of
trace
convention
and
metrics
convention.
D
Do
we
think
that
metrics
attributes
should
be
purely
a
subset
of
trace
attributes?
Just
for
cardinality
reasons?
Does
every
attribute
that
appears
on
a
metric
also
appear
on
a
trace
of
similar
context.
B
I
think
some
attributes,
like
request
sizes,
maybe
better
expressed
as
a
metric
than
attribute,
but
I
think
this
is
all
gray
area.
Nobody
really
did
it
so
far.
D
Internally,
we
want
to
be
able
to
take
traces
and
make
create
metrics
out
of
them,
so
that
is
made
a
lot
easier.
If
the
metrics
convention,
we
can
get
all
the
information
from
the
trace
to
create
a
metric
out
of
it.
E
Does
anyone
feel
like
they
could
take
a
a
first
crack
at
proposing
the
the
default
metrics
that
should
be
in
in
general?
I
would
say
we
kind
of
promised
that
we
were
going
to
focus
on
tracing
in
these
groups,
but
given
that
metrics
is
right
around
the
corner,
if
that
is
interesting
to
somebody,
I
do
think
there's
some
work
to
be
done
there,
so
we
might
as
well
get
cracking
on
it.
So
we
seem
to
yeah.
D
There's
a
few
pieces
of
work
in
the
metrics
convention
that
I've
been
discussing
with
people
here
and
there
and
there's
someone
the
first
thing
to
do
with
the
metrics
convention.
Is
it
needs
yaml?
So
that's
something
that
I've
been
looking
at
with
someone
from
lightstep
just
been
chatting
about
it
on
the
slack
so
yeah
I'll.
I'm
happy
to
keep
my
finger
on
the
pulse
of
matrix
convention,
because
that
is
interesting
to
us.
Yeah
yeah.
E
I
think
the
tricky
bit
it's
not
just
which
metrics
we
want
to
admit
is
the
dimensions,
though
right
like
which
attributes
do
we
want
on
there,
because
that's
you
know,
unlike
traces,
like
that's,
very
pedantic
right,
like
yeah,
you
know
you
can't
just
pile
them
all
on
there,
as
as
we
recently
saw
with
ip,
I
think
getting
on
there
as
one
of
them
in
java.
E
D
That's
one
way
to
blow
up
your
metrics
back
and
just
give
it
lots
of
attributes
yeah,
but.
E
The
plus
side
is
like
this
stuff
is
actually
available
today
in
java.
So
if
people
want
to
review
what's
currently
there,
it's
not
just
not
just
theoretical,
you
can
go
spin
up
a
spring
app
and
play
with
it
and
just
see
what's
what's
coming
out
of
it
currently.
E
E
Well,
all
right!
Well,
dennis
I
think
we
covered
that.
Did
you
want
any
more
feedback
on
on
the
redirects
or
any
of
the
other?
You
have
some
open
pr's
right.
Is
there
stuff
you
wanna
just
like
point
the
group
at
real,
quick.
F
Sure
definitely
I
I
have
this
another
like
a
second
pr
opens
for
retrieves
themselves
and
actually
the
changes
for
the
specification.
So
I
did
this
vr
directly
to
the
specification.
So
there
is
no
odd
tab
for
this
just
because
the
changes
are
really
tiny.
Actually
I
can.
I
can
share
it
in
a
seconds.
F
So
in
these
four
requests
we
do
have.
F
Structure
for
pr
for
retries
and
redirects,
so
the
changes
themselves,
as
I
said,
like
really
tiny.
So
I
just
have
a
proposal
here
to
introduce
retro
accounts
that
can
be
added
to
retries.
Only
so
if
there
is
no
retry,
there
is
no
additional
attribute
and
for
retries
themselves
actually
for
retries
and
redirects.
Actually,
the
the
proposal
is
the
following,
so
we
must
add
a
spam
for
each
try
for
each
physical
try
or
each
physical
redirect,
and
we
like,
we
should
link
it
with
the
previous
one.
F
I
will
shoot
here
because
I'm
not
really
sure
that
it
will
be
possible
actually
to
do
it
within
for
for
all
the
different
implementations,
and
I
do
have
a
couple
of
prototypes
for
this-
for
nets
so
like
for
for
the
general
case.
It
works
great,
so
it's
like
totally
feasible
and
but
like
if
you
want
to
implement
it,
as
as
you
know,
let's
say
in
dot
net
core
core
libraries
like
http
client.
F
We
probably
need
to
do
more
changes
there
and
that's
exactly
what
I'm
focusing
on
right
now
for
for
that
nets
and
also
like
we
are
planning
to
do
some
experimentations
with
java
about
this
just
just
to
just
to
confirm
so
this
was
for
retries
and
for
redirects.
Basically,
the
it
is
really
really
similar.
So
it
also
proposes
that
for
each
redirect
a
new
span
must
be
created
and
it
should
be
linked
with
the
previous
redirect
for
redirect.
F
Like
I
thought
I
don't
have
any
additional
attribute
proposed
yet,
but
we
all.
I
also
had
these
conversations
today
like
internally
microsoft
and
it
might
be
interesting.
So
there
is
a
there
is
a
scenario
when
redirects
count
also
can
be
interesting.
F
So
probably
this
can
be
the
something
that
we
can
discuss
right
now.
So
do
you
guys
think
it
will
be
interesting
to
also
add
like
a
redirect
count
for
redirects
or
we
can
make
make
it
somehow
general
like
I
just
to
have
retry
and
reader
account
and
like
I've,
just
generalized
them
saying
that
it
can
be
something
like
request,
call
or
something
that's
something
yeah.
I
don't
have
full
full
clarity
on
right
now.
H
Yeah,
I
I
don't
know
how
much
redirect
account
would
help
us
in
future
or
like
at
least
help
us
diagnose
any
issues
in
between
service
to
service,
not
that
there
is
an
issue,
but
I
just
hadn't
seen
a
case
where
it
would
be
helpful
for
us
to
look
at.
B
The
case
where
you
want
to
look
at
it
is
like
basically,
every
http
client
has
configuration
for
maximum
redirects
to
follow,
and
the
reason
is
that
you
can
have
circular
reference
and
there
were
like
well
in
my
life.
I
experienced
one
of
those
outages
caused
by
it
so
and
I
don't
think
I
have
too
much
experience
working
on
services.
So
I
assume
this
can
happen
to
other
people
too.
B
E
Like
it
would
be
obvious
from
looking
at
the
trace
that
this
is
a
case,
so
it's
sort
of
like
are
people
going
to
be
creating
like
alerts
or
metrics
or,
like
other
things
out
of
this.
This
attribute.
F
E
F
So
from
this
perspective,
it
definitely
makes
sense,
for
example,
if
you,
if
you
already
see
that
you
have
like
a
redirect
count
more
than
five
ten
or
something
it
can
be,
the
problem
for
from
the
diagnostic
standpoint.
I
believe
it's
something
beneficial.
E
It
seems
great
to
add
as
an
optional
parameter.
You
know
like
these
things.
The
only
reason
I'm
I'm
always
like
a
little
about
anything.
It's
like
it,
creates
overhead
and
you
know,
complexity
and
the
instrumentation,
because
now
you
need
like
a
counter,
and
you
have
to
track
this
stuff,
and
you
know
so
there's
just
like
overhead
and
complexity
that
comes
with
it,
but
I
I
don't
see
any
problem
with
with
making
it
an
optional,
optional
parameter
right
like
go
ahead
and
define
it.
F
Okay,
yeah
so
yeah,
that's
something
that's
what
was
great
to
confirm.
So
I
will.
I
will
make
the
changes
to
this
pr,
but
other
than
that
the
changes
are
really
tiny.
So
I
believe
that's
this
must
we
can?
We
can
put
it
as
must
just
because
it's
like
a
should
be
visible.
I
mean
we
can.
We
can
rely
on
http
clients
instrumentation,
so
for
each
physical
try
it
should
be
possible
so
and
yeah.
I
believe
for
this
for
this
pr.
It's
it's
not
a
big.
E
H
Did
you
also
suggest
that
we
have
a
new
error
type?
As
in
like
the
transitive
error
that
we
discussed
last
week,
I
think
it
was.
F
Yeah
it
was,
it
was
a
discussion
about
this.
I
don't
have
any
prs
open
it
open
for
this
right
now
and
yeah.
I
also
don't
have
it
in
scope
for
http,
just
because
it's
like
a
more
general
problem
right,
so
it's
it
can
be
it
applicable
not
only
for
http
but
for
other
other
different
communications
as
well.
I
probably
do
have
to
have
it
in
my
list.
Just
to
you
know
edit
as
a
as
a
additional
kind
of
hotep
yeah
and
just
start
a
discussion
about
this.
F
I
just
don't
have
spare
time
for
this,
but
yeah.
E
B
H
E
You
know
back
off
and
retry
and
stuff
like
that,
as
is
like
part
of
it
and
it,
it
seems
like,
if
that's
a
feature
that
you
can
use,
then
you
know
it
would
implement
both
transitive
and
marking.
The
final
is
an
error,
but
you
could
still
have
a
client
like
that
and
a
thing
wrapping.
It
that's
trying
to
do
its
own
stuff,
and
I
don't
know
like.
E
Yeah,
I
feel
like
some
of
these
are
cases
where.
Well,
I
don't
know
if
they
have
an
opportunity
to
do
that.
Yeah.
G
E
Don't
know
it's
it's
tricky,
because
if
we're,
if
we're
too
cautious,
then
we'll
have
we
don't
we
want
to
avoid
creating
a
situation
where
there
are.
There
is
like
a
fair
number
of
users
like
doing
relatively
simple
things
at
open,
telemetry
just
isn't
producing
errors
like
they're
gonna,
be
confused
and
irritated
by
that
situation.
E
So
it's
I
think
we
have
to
decide
like
which
side
we're
gonna
err
on
but
yeah.
It
does
seem
like
at
some
point
at
some
point.
Maybe
it's
a
situation
where
we
have
a
good
way
of
turning
off
noisy
things,
so
we
can
have
this
stuff
on
by
default
and
then
for
people
who
are
doing
advanced
stuff
there's
a
way
to
suppress
it.
F
But
right
from
the
implementation
standpoint,
it
might
be
yeah
definitely
tricky
so
for
current,
like
a.net
implementation
or
independent
world,
there
is
http
client
and
the
popular
library
called
poly
for
all
this,
like
resiliency
patterns
and
inside
http
client
itself
is
not
really
possible
to
know.
Is
it
final
one
or
not
the
only
possible
to
do
this
with
poly
so
like
if
we
can
just
come
up
with
a
specification
which
allow
which
bill
can
allow
poly
to
be
instrumented?
E
E
F
That's
the
case
not
only
for
for
like
http
communication,
because
you
can
apply
the
same
like
a
retry
and
like
a
circuit,
breaker
policies
whatever
it
is
all
the
results,
important
policies
for
different
type
of
communication.
You
can,
you
might
want
to
resend
some
message
or
you
might
want
to
like.
I
send
some
additional
query
to
database
yeah
rewrite
the
database
query.
So
from
this
instant
points,
it
makes
sense
to
have
it's
kind
of.
G
E
Of
wonder
if
these
are
cases
where
you
just
end
up
wanting
to
suppress
the
lower
level
instrumentation
entirely
right,
because
that
outer
wrapper
is
going
in
like
most
scenarios,
it's
going
to
look
like
you
know
that
double
instrumentation
stack
that
lumila
hates
you
know.
If,
if
there's
an
outer
layer,
that's
going
to
be
marking
things
as
errors
and
like
managing
retries,
and
that
thing
is
going
to
be
instrumented.
B
To
be
fair,
I
was
thinking
more
like
if
we
ever
spack
out
this
higher
level.
I
was
thinking
about
it,
not
as
a
spam
kind
of
instrumentation,
but
more
like
think
about
some
scope
that
you
say,
or
users
can
set
it.
They
can
use
it
to
mark
404s
and
409s.
They
can
say
okay,
this.
What
happens
after
me
inside
me
is
not
an
error,
don't
treat
it
as
an
error
and
then
on
the
final,
try,
let's
say
they
can
say:
okay,
this
is
the
final
one.
D
B
Internally,
you
can
say:
okay,
this
is
a
transient
error
in
the
instrumentation,
it's
just
multiple
layers
talking
to
each
other
and
we
can
reuse
the
same
mechanism
of
the
scopes
which
are
not
spans
to
for
this
different
configurations
and
just
coordination.
E
Yeah,
it
just
sounds
complicated.
That's
that's.
My
only
concern
that
that's
like
complicated
to
implement
complicated
for
end
users
to
wrap
their
heads
around
it'll,
create
you
know.
I
just
worry
about
those
kinds
of
things.
You
know
and
it's
unfortunate
that
we
don't
live
in
a
simpler
world
where
these
things
are
a
bit
more
standard
and
how
they're
shaped.
B
E
Because
once
you're,
having
like
a
lot
of
just
instrumentation
controlling
other
instrumentation
and
talking
to
each
other,
whether
you
have
a
package
installed
or
not,
it's
like
changing
what
the
instrumentation
coming
out
of
another
package.
I
could
easily
see
end
users
getting
confused
by
that
or
just
the
opportunity
for
a
lot
of
weird
edge
cases
to
pop
up
like
start
starts
to
occur.
Potentially
so,
let's
that's
my
leg
right.
There.
E
Cool,
but
that's
so
as
far
as
like
the
v1
roadmap
is
concerned,
that
seems
like.
E
F
Right
so
I
just
not
like
I
didn't
put
it
there
just
because
that's
the
conversation
that
might
not
be
applicable
for
http
only.
F
But
it's
something
that
probably
can
be
mentioned
as
a
as
a
area
that
we
want
to
investigate
as
an
open
question,
I
guess
open
telemetry,
like
a
general
open
question,
I
would
say.
F
E
B
E
So
really,
as
far
as
the
specific
stuff
in
here,
it
seems
like
the
security
concerns.
F
It's
actually
something
that
probably
can
be
covered
within
the
brit
rice
and
redirects
kind
of
prototype.
Just
because
the
context,
propagation
kind
of
approach
is
something
that's
I'm
using
there
as
well
just
to
propagate
all
the
some
some
content,
at
least
these
counters,
and
to
be
able
to
establish
a
link.
We
also
need
to
have
previous
spam
context.
F
So
that's
exactly
what
I'm
using
there
like.
Currently
I
don't
I
don't.
I
just
don't
see
any
other
use
cases
for
this
so
like
a,
but
if
there
any.
Maybe
it's
like
a
good
to
have
as
a
separate
item.
E
Yeah,
I
guess
all
the
other
things
are
in
kind
of
phoenix,
around
http
2
and
like
transport
level
like
connection
reusage
and
all
of
that
stuff,
right.
Okay,
so
that
just
leaves
security,
as
I
think
we
haven't
tackled.
E
Does
someone
want
to
take
a
first
stab
at
at
least
writing
down
like
what
the
security
problems
are
that
we
want
to
tackle.
E
Right,
well,
maybe
yeah.
That
kind
of
I
guess,
falls
under
security
sort
of
yeah
information
security
but
yeah.
If
there's
like
scrubbing
that
we
feel
like
we
need
to
define,
as
like
a
default
like
easy
to
flip
on
plug-in
or
or
otherwise
like,
basically,
something
something
in
the
collector
that
that
is
easy
to
to
like
include
by
default.
H
E
B
Yeah
and
the
one
thing
we
got
feedback
on
security
from
like
the
dotnet
platform,
folks,
that
it
cannot
leave
application.
So
if
it's
done
only
in
collector,
this
is
probably
not
something
that
they
can
do
so
like
by
default.
They
don't
want
to
give
anything
or
maybe
that
the
thing
that
they
want
is
a
callback.
E
Yeah,
I
think
there
is
room
for
doing
sanitization
as
like
span
processors
and
things
like
that
penny
yeah,
yeah,
oh
and
I
should
go.
I
gotta
go.
Sorry
sounds
like
we
might
be
running
to
the
end
here,
but
I
gotta
run
well
well.
Thank
you
again
dennis
for
doing
all
this
work
and
james
and
everyone
else
for
for
taking
up
some.
Some
slack
here
appreciate
it.
Thank
you
see.
F
Yeah
one
thing
that
I
wanted
to
add
about
security
concerns
is
that
we
also
were
discussing
this.
I
attribute
extractor
apa-
that's
probably
already
exist
in
java
worlds,
and
this
is
something
that's
like
some
some
intermediate
api
that
can
be
used
to
extract
data
information,
attributes
from
http
request
and
this
something
that
probably
can
also
fulfill
this
requirement
for
security
concerns.
So
that's
exactly
the
one
that
can
be
used
for
synthesization
from
like
a
first
digitization.
F
F
That's
something
that
can
be
can
be
can
sit
actually
between
http
clients
or
the
the
coalition
security,
and
when
you
have
the
information
about
http
request
and
the
open-source
instrumentation
library,
so
basically
instrumentation
library
can
use
default
implementation
of
extractor
just
to
get
all
the
information
that
we
have
right
now
in
specification.
But
if
the
user
wants
to
do
something
else,
for
example,
just
to
scrub
some
values.
So
since
they
tie
some
values,
that's
that's
the
exactly
the
way
how
it
can
be
done.
D
G
I
was
just
gonna
start
had
conversations
with
our
security
team
for
years
about
this
right
and
the
the
tldr
is
that
you
cannot
do
any
post-processing
to
and
gain
confidence
that
you've
scrubbed
the
right
data,
and
this
is
why
it
comes
back
to
the
generation
of
the
data-
has
to
be
secure
right
and
there's.
There's
a
bunch
of
teams,
cheering
confluence
to
it
slightly
differently,
but
at
the
end
of
the
day
they
have
a
couple
of
safeguards.
G
The
other
massive
spanner
here,
that's
going
to
destroy.
All
of
this
is
our
security
intelligence
teams
want
that
raw
data
right,
so
they
actually
want
unfiltered
data
so
that
they
can
do
all
of
their
security
investigations.
And
then
we
do
have
all
sorts
of
processes
later
to
lock
down
that
data
and
whatnot.
But
that
means
that
if
we're
generating
scrubbed
we'll
call
it
data
security
won't
be
happy,
but
if
we're
sending
unscrubbed
data
developers
won't
be
happy.
G
So
there's
this
real
and
we've
not
solved
this
yet
other
than
scrubbing
in
pipeline,
which
never
works
so
yeah
I'll
document
as
best
I
can,
but
it
generally
comes
down
to
developers
having
a
model
like
a
semantic
invention
that
they
follow
for
all
things
so
span
names,
for
example,
instead
of
using
urls
and
and
things
like
that,
create
jira
issue
as
the
end
point
and
not
including
the
jira
issue
key
and
things
like
that.
G
I
can
document
all
this,
but
it's
it's
a
quagmire
of
conflicting
concerns
and
I'm
not
100
sure
that
hotel
really
should
be
aiming
to
solve
this
in
any
v1
right.
I
think
that
we
should
be
aiming
to
get
all
of
this
into
as
much
production
as
possible
and
then
tweaking
versus
trying
to
come
up
with
the
best
best
ferrari
out
of
the
gate.
B
Problem
here
is
all
the
auto
instrumentations
right,
so
in
the
perfect
world,
applications
don't
need
the
right
instrumentation
code,
at
least
some
baseline
right
and
then
all
the
other
instrumented
http
clients
or
all
the
bytecode
instrumentations
and
monkey
blushing.
They
they
have
no
way
of
scrubbing
at
all
unless
they
maybe
do
a
callback
somewhere.
F
Yep
when
it
comes
to
specification,
I
believe
we
just
need
to
point
out
like
which
attributes
can
have
sensitive
values
and
should
be
treated
somehow
differently,
but
the
exact
solution
is
not
something
probably
which
is
which
we
can
done
on
http
level.
I
believe
the
same
exact
problem
exists
for
for
other
types
of
communication
right.
H
G
Yeah,
I
don't
think
it's
too
much
for
a
developer
to
have
to
when
instrumenting
name
something
or
give
us
a
piece
of
context
about
that
thing
like
to
automatically
instrument
everything
and
take
all
load
off
of
developers
so
that
they
can
get
everything
for
free.
But
that
then
means
we
need
to
come
up
with
some
amazing
scrubbing
technique
which
I
don't
think
exists.
G
F
G
G
Just
the
the
idea
that
not
all
dimensions
attributes
are
equal
right.
Like
you
say,
some
amount
of
attributes
do
some
pre-pressing.
Some
of
them
are
not
processed
some
of
them.
You
know
and
actually
defining
a
model
that
we
can
follow
through
metrics
spans
everything.
You
know
we
have
that
internally.
Now,
where
we
have
a
basically
an
allow
list
of
dimensions
that
we
don't
do,
cardinality
checks
for
and
then
everything
else
gets
cardinality
checks
in
the
pipeline,
and
it
would
be,
I
think,
that's
a
pretty
common
concern
for
everybody
in
observability.
So
anyway,.
D
See
like
even
those
required
attribute
sets
like
they're
required,
and
I
can
see
that
some
of
them
could
have
pii.
So
it's
like
for,
like
even
net
dot
peer
dot.
Ip
is
like
a
that's
like
could
be
pii.
So
so
it's
like.
D
G
And
look,
for
example,
in
our
action
p
metric
sets
weed
strip
ip
post
and
all
those
things
just
for
cardinality
reasons.
Right.
G
F
Right
from
from
the
open,
selector
perspective,
I
believe,
like
the
best
we
can
do
is
just
to
you
know,
specify
which,
which
data
can
have
this
sensible,
sensitive
information
and
how
actually
to
deal
with
this
right,
like
which
api
I
need
to
use
or
like
which
approach
you
need
to
use.
Should
it
be
callback
or
just
separated
api
or
whatever?
It
is
just
for
end
developers
to
describe
them
or
to
facilitate
all
this
data
and
looks
like
the
same
problem
exists
for
like
for
many
different
companies
and
different
many
different
type
of
communications.
F
D
D
Like
auto
instrumentation
like
reading
this
magic
invention,
would
there
be
like
some
kind
of
flag
in
the
yaml
that
would
that
would
tell
that
or
because
it
can
be
written
in
the
convention,
but
like
how
does
the?
How
does
it
happen?
Programmatically.
G
Maybe
I
need
to
write
this
otep,
but
take
the
our
pipeline,
for
example
right
if
we
didn't
have
to
have
allow
lists
and
rules
in
the
pipeline,
and
we
just
looked
at
the
data
and
said:
okay,
the
developers
marked
this
as
could
be
sensitive
and
therefore
send
it
to
security,
delete
it
from
the
payload
other
things
like
that.
Around
cardinality
control,
for
example,
like
we
know
that
the
developers
said
that
we
trust
this
and
it's
in
a
while
list
or
something
so
we
won't
do
much
processing
on
this.
G
You
can
deal
with
it.
Not
my
problem
in
atlassian
will
delete
that.
H
Yeah,
so
I've
previously
raised
an
otep
that
is
loosely
related
to
this,
whereas
having
the
idea
of
sensitive
data
labels
not
to
the
extreme
specifics,
but
it
could
be
fleshed
out
to
include
more
and
more
of
this
conversation.
G
Yeah
and
the
problem
is
the
the
moving
goal
posts
here
right.
So,
as
you
get
bigger,
more
things
become
sensitive
as
you
go
through
the
compliance
circus,
so
yeah.
H
Oh
good,
I've
just
been
adding
this
to
the
agenda
items
so
just
as
like
discussion
points.
H
H
G
H
F
I
believe
it
it
is.
It
is
reasonable,
so
if
we
can
just
make
first
step
here
for,
for,
we
want
just
to
to
make
it
kind
of
covered
in
terms
of
at
least
just
pointing
out
this
something
can
contain
this
kind
of
information.
I
believe
it's
it's
already.
It's
already
a
good
idea
for
everyone,
but
yeah
all
the
subsystem
subsequent
kind
of
discussions,
how
it
can
be
done
in
which
a
or
like
a
which
approach
should
be
used.
F
I
believe
it's
not
really
http
specific
and
for
the
next
versions
of
http
conventions.
We
can
do
some
more
kind
of
prototyping
and
get
more
more
idea
how
we
can
treat
it.