►
From YouTube: 2022-08-25 meeting
Description
OpenTelemetry Prometheus WG
A
B
A
good
amount
of
people
here
so
yeah
all
right.
Well,
let's
go
ahead
and
get
started
all
right.
Well,
so
welcome
back
everybody
for
those
who
are
new
here,
it
looks
like
there's
some,
I
guess
new.
Maybe
you
came
to
one
of
the
earlier
ones,
but
this
is
the
profiling
meeting.
I
guess
the
almost
official
working
group
who
we've
been
working
for
a
couple
months
now
on
getting
profiling
accepted
as
an
event
type
for
hotel
yeah,
and
so
we
in
the
more
rece
you
know
earlier.
B
We
started
off
getting
a
bunch
of
overviews
of
various
formats,
both
ones
that
you
know
the
communities
and
languages
are
using
heavily
like
pprof
and
then
jfr
and
then
also
some
like
custom
formats
for
profiling
that
various
companies
shared
that
they
were
doing
yeah
and
so
now,
over
these
past
couple
weeks,
we've
shifted
to
basically
creating
an
otep
and
yeah.
Last
week
we
made
a
lot
of
progress
on
that.
I
shared
it
with
the
what
we
came
up
with
with
the
specifications
sig
and
they
had
some
kind
of
recommendation.
B
I
mean
yeah.
They
they
liked
it.
So
far.
They
had
some
recommendations
on
on
things
we
could
do
moving
forward
and
that's
sort
of
where
we
are
at
right
now
so
for
today
feel
free.
If
there's
other
stuff,
you
want
to
add
to
the
agenda,
to
add
it
to
the
agenda,
but
things
that
would
be
good
to
you
today.
I
pasted
the
otep
in
there
a
lot
of
people
added
some.
B
B
I
guess
is
there
anything
that
anybody
thinks
that
it's
missing,
that
yeah
looks
or
I
guess,
for
those
who
added
extra
elements.
I
see
sean
you
added
something
about
performance
in
there.
Since
we
last
spoke,
we
added
some
use
cases
yeah,
I
don't
know
yeah.
Do
you
want
to
kind
of
talk
about
the
the
section
you
added
sean.
A
So
I
kind
of
wanted
to
I
don't
ryan.
Do
you
maybe
want
to
share
your
screen?
So
people
can
see
it's
kind
of
specifically
what
we're
talking
about.
Maybe
this
document
isn't
even
the
place
for
this.
I
I
don't
know
I
guess
it's
yeah.
I
guess
kind
of
cards
on
the
table
like
when
I
say
some
systems
operate
like
this.
Obviously,
ours
is
one
of
them.
That's
why
I
care
about
this
and
yeah.
C
A
B
Yeah
yeah,
I'm
curious.
If
others
have
thoughts,
I
mean
I
don't
think
it's
too,
I
mean
yeah
again.
The
goal
of
this
dock
was
to
be
sort
of
high
level.
You
know
the
main
thing
being
we
wanted
to
make
sure
that
the
yeah
that
people-
I
guess,
yeah-
that
you
let
me
see-
let
me
pull
up
yeah
so
yeah.
So
this
is
like
the
the
project
management
piece
that
I
was
just
talking
about.
That
was
added
to
yeah
like
30
days
ago.
B
So
we're
kind
of
the
first
group
that's
going
fully
through
this.
You
know
so
one
of
the
requirements,
a
group
of
subject
matter
experts
you
know
deciding
to
spend
time.
We've
definitely
been
doing
that
a
portion
of
the
tc
being
aware
we
have,
you
know
also
done
that
made
them
aware
and
then
I
believe
yeah
josh
is
on
here
now
and
then
the.
B
Welcome
josh
yeah
we'd
love
to
get
your
opinion
on
some
of
this
too
and
yeah.
If
you
want
us
to
kind
of
go
through
and
recap
more
in
depth,
let
us
know
but
yeah
and
then
the
last
one
is
making
the
broader
community
aware,
and
so
this
stock
was
mostly
aimed
at
this
area
from
the
feedback
we
got
from
our
other
tc
representative
from
tigrun.
B
For
that
reason,
and
I
think
that
this
kind
of
helps
satisfy
that
giving
a
good
high
level
overview
of
you
know
what
the
general
things
we're
thinking
about
are
and
the
future
sort
of
efforts
that
we
do
will
go
more
into
depth
with
into
you
know,
yeah
what
all
this
actually
means
in
practice.
That's
my
opinion,
curious.
If
anybody
else
has
thoughts
on
that.
D
C
D
Okay,
I
also
get
excited
to
talk
too
much
so
we'll
maybe
I'll
use
my
hand
in
the
future.
One
thing
I
want
to
say
about
the
performance
thing
that
I
think
is
important
to
this
overall
document
is
like
the
the
use
case
or
like
target
you
know.
Uses
of
this
signal
is
kind
of
important
this.
This
discussion
happened
a
bit
late
with,
say
tracing
around
like
http
instrumentation
around.
D
Are
we
making
trace
instrumentation
for
people
who
develop
the
http
server
or
for
people
who
monitor
http
applications
and,
like
you
know,
you
have
to
pick
your
your
user
scenario
in
performance
here?
I
think
the
most
important
thing
that
you
need
to
communicate
is:
you
are
you're
targeting
this
at
people
who
want
low
overhead
profilers
low
overhead
distributed.
It
can
be
usable
for
high
overhead,
but
like
what
I
read
here
is
low.
Overhead
is
a
use
case
that
needs
to
be
accounted
for
and
optimized
for
is
that
correct.
C
C
C
You
know
flexibility
like
these
sort
of
design
precepts
as
guiding
stars.
I
think
make
a
lot
of
sense,
and
so
I
think
I'm
really
happy
to
see.
I
think
sean
put
this
in
this
section,
because
it
kind
of
it
neatly
captures
in
two
paragraphs
a
bunch,
but
maybe
maybe
we
would
just
add
or
leave
as
is,
but
I
I
think
it's
an
important
part
of
the
doc,
because
it's
really
easy
to
make
one
for
just
one
use
case.
A
B
Yeah
I
mean
you
can
kind
of
quickly
skim
through
the
rest
of
these
yeah.
There's
I
mean
yeah,
I
guess,
there's
there's
some
kind
of
information
along
those
lines
in
aligning
with
the
overall
open
telemetry
goals,
making
profiling
easy,
bender,
neutral
yeah.
These
are
kind
of
just
points
that
are
taken
from
the
open,
telemetry
gold,
but
also
things
that
we've
talked
about
internally
yeah,
as
it
currently
stands.
Kind
of
the
the
problem
here
is
that
you
know
that
profile
profiles
collected
can
vary
a
lot.
B
You
know
based
off
language,
profiler
type
data
being
profiled
things
like
that.
Let's
see
yeah
one
of
the
other
things
that
we've
talked
a
lot
about
here
in
both
sort
of
like
a
long-term
goal
for
where
profiling
fits
into
the
rest
of
the
you
know,
or
the
rest
of
the
signals
is
that
it
should
be
compatible
with
those
other
signals,
and
so
that's
something.
We've
also
talked
about.
B
I
pasted
in
a
talk
that
liz
fong
jones
made
at
the
at
the
observability
tag
meeting
where
she
talked
a
lot
about
that
had
some
interesting
kind
of
insights
there.
If
you
haven't
had
a
chance
to
check
that
out,
yeah
and
then
obviously
the
section
we
were
just
talking
about,
I'm
defining
a
stable
profiling
model.
B
Yeah
I
see
andre
is
here.
I
don't
know
if
you
I
know
you
work
on
jfr
or
I
guess
java
profiling.
Some
would
be
curious
if
you
have
thoughts
here,
we've
heard
from
some
yeah
from
p
prof
people
yeah,
I
don't
know
some
other
areas,
but
but
anyways
yeah.
One
of
the
things
we
also
talked
about
was
that
for
popular
profilers
that
already
exist
that
we
want
to
make
sure
that
we
don't
sort
of
get
too.
I
guess
yeah
that
it's
not
too
hard
to.
B
B
B
A
B
D
D
So
if
you
think
you're
going
to
have
a
lot
of
points
that
need
some
nuance
to
go
into
detail
so
that
you
don't
get
as
much
contention,
it's
okay
to
be
longer
logs
had
very
little
contention
across
the
ecosystem
as
something
to
pick
up.
It
did
have
some
contention,
that's
addressed
in
that
otep,
but
you
know
it's.
It's
also
tigran's
pretty
good
at
being
very
minimal
with
how
he
writes
things.
So
it's
a
good
one
to
compare
against
it.
D
B
Cool
also
something
that
tigra
and
tyron
talked
about
is
that
it's
not
necessarily
like
set
in
stone,
but
this
is
more
just
yeah.
We
can
always
yeah.
I
guess
the
goal
is
to
get
this
to
a
point
where
we
it's
generally
agreed
upon,
where
we
can,
you
know,
put
it
in
move
it
from
this
dock
into
github
and
then
sort
of
share
more
broadly,
and
we
can
always
kind
of
tweak
it
or
you
know,
do
whatever
to
it.
Then
I
guess
I
just.
I
think.
B
Yep
yeah,
so
I
guess
that
I
mean
that
is
one
thing
we
can
definitely
do
maybe
offline
as
well
as
kind
of
yeah.
If,
as
people
read
through
this,
if
they
think
that
there's
certain
parts
that
are
a
little
wordier
or
that
are
a
little
more
fluffy
than
they
need
to
be
and
could
be
either
you
know,
shrunk
down
or
stripped
out,
definitely
feel
free
to
comment
in
this.
B
B
A
B
So
far
with
everybody
who
we've
shared
this
with
I
mean
this,
is
we
kind
of
yeah
tried
to
strike
a
balance
with
this
and
being
you
know,
addressing
as
much,
you
know,
contention
points
that
we've
had
sort
of
internally
in
our
discussions
and
when
sharing
with
the
specifications
group,
which
is
the
only
group
so
far
that
we've
shared
it
with
there
have
not
been
major
contentions,
but
I
guess
you
know.
That's
kind
of
the.
B
The
next
step
in
this
process
is
to
sort
of
put
this
out
there
and
see
yeah
if
there's
other.
You
know,
groups
that
have
not
been
as
active
in
this
process
who
do
have
concerns
about
what
we've
outlined
here
so
yeah.
To
answer
your
question,
there
haven't
been
many
that
have
been
made
aware
that
we've
been
made
aware
of,
but
I'm
sure
that
there
will
be
some
out
there
as
there
always
are
with
these
kinds
of
things
josh.
I
think
you
were
next
or
thomas
sorry,
thomas
myself
has
handled
them
before
josh.
D
Yeah,
so
I
was
actually
gonna
directly
address
some
contention
points,
just
things
to
think
about
the
one
I
the
one,
the
one
that
I
think
you
already
saw
was
why
open
telemetry
for
this
right?
That's
that's.
I
think
the
most
important
argument
is
how
profiling
aligns
with
the
vision,
how
it
fits
in
how
it
works.
The
second
thing
to
think
about
is
folks
who
own
instrumentation
in
a
hotel.
D
What
does
profiling
mean
to
them
like?
Are
they
going
to
be
responsible
for
integrating
with
profiles?
Is
it
separate
instrumentation?
Is
it
new
developers
a
new,
you
know
community
there,
or
are
they
going
to
view
this
as
just
more
overhead
for
them?
So
that
would
be
a
second
point
of
contention
that
I'd
address
there
may
be
more,
but
I
think
those
are
kind
of
the
two
big
ones
that
you're
likely
to
see.
D
And
I
think
you
already
have
that
with
how
profiling
aligns
with
open
telemetry
vision.
So
I
just
want
to
clarify.
I
think
that
one's
accounted
for
and
is
the
most
important,
but
the
second
one,
I'm
not
sure.
If
that's
kind
of
fully
addressed
in
this,
it
may
not
need
to
be
addressed
in
the
proposal.
It
may
need
to
be
addressed
in
comments
so
I'll
leave
that
up
to
you
guys.
D
D
B
B
B
C
B
A
A
D
Answer
no
like
so
here's
the
here's,
the
pro
you're,
the
first
signal
to
get
added
to
open
telemetry.
So
there's
no
on-ramp
process
and
we've
been
talking
about
this
in
the
tc
about.
Should
we
make
one
well,
I
mean,
let's
see,
if
there's
a
like
another
signal
that
comes
after
this
one.
So
to
some
extent
there
might
be
some
rough
bumps
here,
as
we
figure
out
a
process.
Oteps
are
not
designed
for
this
kind
of
document.
D
Oteps
are
more
supposed
to
be
actual,
like
here's,
a
proposal
that
is
more
fleshed
out
and
more
defined
like
I
would
expect
the
otep
for
profiling
to
be
here
is
the
otep
for
what
the
signal
looks
like
in
the
protocol
right,
that's
kind
of
more
what
it's
designed
for.
We
don't
have
a
a
mechanism
in
the
community
for
this
particular
proposal,
and
this
kind
of
thing
of,
let's
add
profiling.
Just
in
general
otep
is
our
best
way
to
get
the
right
people
to
review
that
document
and
approve
it
so
we're
leveraging
oteps
for
it.
D
You
will
look
different
than
oteps,
though
that's
so
that's
my
current
opinion
and
that's
that's
kind
of
the
recommendation
to
go
with
otep
is
you'll.
Look
different.
It's
okay!
We
don't
have
a
signal
onboarding
ramp
with
a
thing
that
looks
right
for
this
kind
of
document.
The
the
objective
of
this
document
should
be,
and
you
can
write
at
the
top.
If
you
want,
we
can
be
very
clear
like
if
this
open
is
accepted.
It
means
work
to
define
and
propose
the
profiling
signal
will
occur
right.
D
C
A
Yeah
just
one
final
thing
on
the
dock:
at
the
end,
we
have
the
profiling
use
cases
and
I
think
we're
probably
like
repeating
ourselves
a
little
in
a
few
of
them,
which
is
totally
fine
to
start
with,
like.
I
think
this
is
just
kind
of
a
good
scratch
pad
to
work
with,
but
we
probably
want
to
kind
of
workshop
these
a
bit
and
just
make
sure
they're
not
too
repetitive,.
B
That
makes
sense
yeah.
I
think
I
was
thinking
the
same
thing.
I
think
we
could
probably
maybe
even
sort
of
like
make
them
more.
Like
outline
format,
I
feel
like
there's,
probably
some
themes
between
different
ones
of
them
that
fit
in
with
the
sort
of
yeah,
like
the
various
use
cases
that
we
mentioned
up
here.
You
know
some
are
about
like
linking
to
other
signals.
Some
are
about.
You
know
yeah
other
pieces,
so
yeah.
B
A
A
quick
note
for
titles
for
section
titles
like
defining
a
profiler,
stable
data
model.
I
wonder
if
it
can
be
re
rewarded
to
focus
more
on
what
we
actually
want
to
achieve,
because
defining
a
data
model
is
more
like
means
to
an
end,
but
if
I
would
be
like
looking
at
the
old
app
what
is
kind
of
like
what
is
the
actual
value,
so
I
think
the
message
here
is
really
about
like
we
want
to
make
sure
that
it
can
be
used
by
different
vendors
and
like
it
can
or
something
like
that.
A
B
Yeah
feel
free
to
do
that.
Yeah,
I
would
love.
I
I
think.
That's
that's
fair
yeah,
maybe
also
offline
yeah,
feel
free
to
kind
of
suggest
any
yes,
you
just
kind
of
which
what
might
work
better
there.
I
guess
this
is
kind
of
a
bra.
This
yeah.
I
guess
this
one's
kind
of
broad
and
fits
a
lot
of
things
under
it.
So
for
like
a
title.
B
B
A
So
one
my
my
tiny
bit
of
feedback
for
the
state
of
profiling.
I
this
may
be
some
personal
bias,
honestly,
not
like
from
my
seat.
I
sit
in
working
on
what
I
do,
but
I
like
seeing
taxonomies
and
I
feel
that
we
could
add
a
little
bit
of
nuance
and
granularity
and
say
here's
kind
of
the
types
of
profilers
that
are
out
there
there's.
You
know
obviously
ebpf
based.
B
A
A
Yeah,
just
to
tag
onto
that,
I
I
forget
who-
and
I
apologize
if
you're
on
the
call
the
person
that
assembled
that
but
there's
this
really
comprehensive,
like
state
of
state
of
profilers
that
exist
in
the
world
out
there
and
I'll
try
and
find
it.
But
if
anybody
knows
what
I'm
talking
about
it
could
be.
A
good
thing
to
link
to
from
here
is
what
I
was
thinking.
A
C
Right
now,
categorically
went
through
all
of
them
and
and
and
mapped
them
all
out.
I
was
gonna
say
just
a
plus
one
on
the
taxonomy
bit
too.
You
know
we're
all
kind
of
in
this
bubble,
but
people
reviewing
this
otep
or
people
reading
it
from
the
outside
looking
in
might
not
really
get
the
distinct.
Get
that
we're
making
choices
you
know
around.
Is
it
called
attributed
profiling?
Is
it
sampling
profiling?
C
B
B
B
He
was
saying
that
that,
while
we
have
a
lot
of
momentum-
and
you
know
interest
in
moving
forward
with
things
that
we
shouldn't
necessarily
like-
you
know,
stop
everything
and
wait
for
that,
but
that
we
can
do
some
things
that
we've
talked
about
in
parallel,
one
of
the
things
that
he
mentioned
and
that
yeah
we
also
talked
a
little
bit
about
at
the
specifications.
Sig
was
the
benchmarking
stuff.
There
will
be
multiple,
and
I
guess
by
that
I
mean
yeah.
I
guess
benchmarking.
B
You
know.
Ultimately,
if
we
do
come
up
with
a
new
format,
there
will
be
a
need
to
benchmark
that
particularly
relative
to
other
formats,
and
so
he
you
know
yeah.
So
that's
something
that
is
on
the.
I
guess
sort
of
that's
the
only
thing
I
would
say
work-wise
that
we've
even
briefly
talked
about
that's
sort
of
like
on
the
the
road
map.
We
did
talk
about
how
there
are
multiple
kinds
of,
or
I
guess,
multiple
metrics-
that
we
will
need
to
ultimately
benchmark
but
yeah.
B
One
of
those
is
just
the
format
itself,
particularly
around
yeah,
one
of
the
things
that
tigrun
mentioned
was.
Why
can
we
not
just
use
the
standard,
I
guess
like
hotel
events
for
profiling
data
and
so
so
yeah.
So
I
added
some
stuff
here
around
potentially
just
like.
As
a
first
step
to,
I
guess,
yeah,
I
kind
of
get
the
ball
rolling
on
writing
actual
code
to
analyze.
B
This
is
maybe
just
like
benchmarking,
the
hotel
format
itself
and,
and
then
hopefully,
whatever
we
come
up
with,
would
be
more
efficient
than
that
and
at
least
make
a
case
for
why
you
know
a
standardized
format
would
be
better
than
just
like
standard
hotel
events.
That's
up
for
discussion,
there's
a
doc
that
better
explains
all
of
this
yeah.
That
kind
of
explains
both
a
method
that
we
could
use
to
sort
of.
B
D
I
just
want
to
call
out
tigran
has
some
benchmarking
code,
that
for
is
not
in
open
telemetry,
for
some
reason
that
we
use
to
benchmark
the
changes
to
the
open,
telemetry
protocol
in
the
sense
of
a
collector.
So
one
use
case-
I
don't
know
if
you've
thought
about,
but
in
open
telemetry.
We
have
this.
You
know
agent
that
basically
sits
between
where
you
generate
telemetry,
where
it
goes,
the
idea
being
to
open
up
freedom
for
everybody.
D
So
one
really
important
part
of
the
protocol
is
not
just
generating
the
data
and
getting
it
on
the
wire,
but
also
how
fast
it
flows
through
these
things.
If
users
want
to
say
add
you
know
additional
labels
or
something
to
that
data.
So
I
would,
I
didn't,
have
a
chance
to
read
through
the
benchmarking
document:
apologies
if
this
is
already
there,
but
just
that
as
a
use
case
as
well,
to
consider
nice.
B
A
B
You
know
that
we
would
have
with
like
known
deliverables,
and
so
we
just
know
that
at
some
point
this
will
be
a
known
deliverable,
I'm
more
just
mentioning
it
now,
as
just
like
the
type
of
or
yeah
something
that
we
would
put
first
on
the
project
board,
just
because
we
already
have
it.
However,
there
are
going
to
be
various
things
that
we
will
have
on
that
board,
long
term
and
so
yeah.
B
B
For
example,
coming
up
with
a
more
specific
you
know,
format
of
like
you
know
what
actual
fields
are
in
a
profile
and
that
kind
of
stuff
you
know
yeah
coming
up
with
some
of
those
more
specific
things.
That's
another
example:
coming
up
with
some
sort
of
benchmarking,
suite
and
methodology
is
another
example.
We
talked
about
getting
a
lot
of
different
profiles
for
that,
so
collecting
profiles
from
you
know
various
languages,
various
you
know
sort
of
different
use
cases
that
kind
of
thing
so
yeah.
B
All
of
these
are
things
that
we've
talked
about,
that
we
can
add,
but
yeah.
I
just
wanted
to
put
it
out
there
that,
assuming
that
you
know
all
does
go
well
with
this,
that
we
will
need
to
start
populating
that
project
board
with
all
of
the
things
that
we
have
so
far
kind
of
like
put
off
for
the
future.
You
know
yeah.
C
I
I
I
think
one
place
that
we
left
the
stock
and-
and
I
think
the
just
for
folks
that
are
new
to
this
meeting
series.
We
kind
of
went
down
this
brainstorming
rabbit
hole
around
benchmarking
and
realized.
I
think
that
we
didn't
have
that
higher
level
vision,
dock
to
kind
of
bring
things
together,
and
it
was
already
a
little
bit
in
the
weeds,
for
example,
should
the
benchmarking
suite
be
lossy
or
lossless
right?
C
B
Yeah
correct
no,
as
far
as
I
know,
none
has
but
and
yeah.
So
I
think
this
would
be
a
good
time
to
sort
of
revisit
it
and
re-view
it
under
the
lens
of
what
we've
kind
of
talked
about.
You
know
in
the
in
the
sort
of
broader
vision,
doc
and
see.
If
you
know
again,
everything
still
makes
sense
if
it's
still
like
along
the
lines
of
what
we
yeah
kind
of
outlined
in
that
vision,
doc.
C
Yeah
cool,
I
think
the
same
approach
would
work
here.
You
know
in
that
we,
I
think
it
was
josh's
points
that
you
know
what
does
this
mean
for
current?
You
know
authors
and
maintainers
of
open
telemetry,
existing
stuff
or
new
profiling
stuff.
You
know
so,
for
example,
when
I
think
about
this
benchmarking
suite
you
know,
I
think
it
should
make
it
easy
for
me
to
come
up
with
a
new
optimized
implementation
of
some
chunk
of
this
thing
that
I
can
swap
out
and
see
how
that
affects
the
entire
thing
like
so
so.
C
For
me,
it
would
be
a
developer
focus,
good,
ux
tool
right
so
that
I
can
mix
and
match
different
implementations.
You
know
to
test
and
verify
and
do
stuff
like
that,
but
other
folks
might
have
a
very
different
idea
about
what
it
means
to
benchmark
the
profiler
right.
So
maybe,
if
we
in
the
coming
weeks
focus
for
this
talk
on
those
like
high
level,
things
that
are
the
scenarios
that
you
know
we
might
have
implicit
understanding
of,
but
aren't
explicitly
laid
out
to
the
uninitiated
to
to
be
able
to
discover.
C
B
C
B
B
Yeah,
I
think
this
one
so
yeah,
so
this
is
kind
of
what
yeah.
So
you
know
they
have
like
trace
id
span
id
flag
severity.
You
know
they
have
like
a
bunch
of
things
outlined
in
here
so
yeah.
This
is
like
another
thing.
We
would
ultimately
need
to
come
up
with
and
discuss.
So
that's
one
thing
we've
talked
about
and
then
another
is
yeah
and
then
also
like
whatever
things
end
up
in
this
stock
kind
of
yeah
documenting
the
or
benchmarking
I
guess
converting
to
to
that
format
or
something
so
anyways.
B
B
And
then
the
last
thing
on
the
agenda,
unless
anybody
has
anything
else
they
want
to
add,
is
that
there's
yeah?
I
don't
know
we
again.
It
might
be
a
little
early
to
start
talking
about
timelines,
but
I
mean
yeah
now
that
things
are
starting
to
take
shape
more.
We
can
start
thinking
about
coming
up
with
more
timelines.
B
There's
like
cubecon
in
october.
I
feel
like
that
might
be
a
good
time
to
share
what
progress
we've
made
with
people.
Just
it
was
just
kind
of
something
yeah
I
don't
know,
take
it
or
leave
it.
I
just
felt
like
that.
I
know
last
time
at
the
last
kubecon
in
europe
there
was
a
lot
of
talk
about
at
the
hotel
sort
of
meeting
about
profiling
in
general
and
it
being
something
that
people
thought
that
should
be
a
priority
moving
forward.
They
did
like
this
big.