►
From YouTube: 2021-04-13 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
A
Perfect,
okay,
we
can
start.
I
think
five
minutes
past
start
time,
thanks
for
joining
as
usually
we
only
have
a
pair
of
items.
So,
let's,
let's
start
with
the
first
one.
So
this
is
about
semantic
conventions,
guidelines
and
some
changes
that
were
proposed
regarding
using
lowercase
for
for
the
values
in
the
specification,
there's
a
link
pr.
I
think
it
makes
sense
to
have
this
change,
but
only
three
people
have
reviewed
that,
so
we
need
more
eyes.
That's
the
first
thing,
the
first
thing.
A
B
B
I
don't
know
if
that's
a
reason
to
delay
this
delay
releasing
this,
but
we
could
hold
on
to
it
to
the
next
release
cycle
at
least
and
see
if
we
can
get
some
other
semantic
convention
changes.
A
Yeah,
I
have
the
same
feeling
to
be
honest.
If
somebody
disagrees
with
that.
Besides
hello
lita,
please
raise
your
voice,
otherwise
we
can
pop
her
since
she's,
not
here,
so
she
can
give
her
reasons
and,
depending
on
that,
I
will
either
do
the
release
today
later
today,
with
or
with
or
without
this
part
make
sense
right.
So
let's
try
to
postpone
them
very
good.
The
second
item
is
regarded
in
spanzer
status.
A
There's
an
issue
that
nikita
field-
and
we
we
were
talking
about
this
for
some
days
now-
and
this
is
regarding
whether
like
if
the
user
sets
these
like
two
status-
okay,
but
then
the
instrumentation
wants
to
set
that
this.
There
was
an
error,
but
how
to
know
that
the
user
already
said
this
already.
A
So
there
are
three
possibilities
to
do.
This
first
is
having
spam
get
the
status.
So
instrumentation
knows
that
if
there
is
a
new
error,
but
the
user
already
said,
okay,
then
you
don't
override
that
the
problem
with
this
is
that
if
we
were
to
have
a
streaming
a
streaming
implementation,
then
this
couldn't
work
and
also
this.
This
would
kind
of
break
the
current
approach,
which
is
we
don't
expect.
We
don't
provide
getters,
it's
mostly
grade
only
api.
A
The
second
option
is
about
actually
allowing
spam.
You
know
set
status
to
have
a
source,
so
you
know
who
was
selling
this
this
value,
and
we
had
this
in
the
past
as
part
of
your
of
eurotep
says:
yeah,
basically
just
yeah
to
signal
who
are
selling
this
like
either
the
user,
the
instrumentation
you
know
so
and
then
a
smarter
decision
can
be
made
and
the
final
option
is
just
having
one
additional
method
called
set
status
if
not
set,
which
would
be
just
something
like
a
trade-off.
A
Personally,
I
like
more
option
two,
but
I
am
a
little
bit
afraid
that
it
may
break
the
products
and
it
also
may
break
apis.
I
don't
know
how
it
is
implemented
in
all
the
languages,
but
I'm
afraid
that
it
may
not
be
so
easy
to
just
go
on
at
this.
A
So
basically,
we
were
talking
about
having
an
alternative
streaming
implementation.
That
is
not
keeping
information
in
memory.
You
are
just
sending
everything
over
the
wire,
and
because
of
this,
you
cannot
keep
or
you
are
not
supposed
to
keep
a
lot
of
stuff
in
memory,
including
state
like
this.
That's
one
of
the
things.
The
second
thing
is
that
we
have
this
approach
of
trying
to
not
provide
gathers,
which
is
more
a
philosophical
thing.
I
would
say,
yeah.
B
That's,
I
guess
that's
what
I'm
saying,
but
what
we
currently
we've
tried
to
restrict.
What
we
keep
in
memory
is
basically
what's
defined
in
trace
context,
essentially
right.
A
F
To
do
I
mean
it
does
require
I
mean
the
concept
was
that
this
requires
you
to
keep
a
span
object
and
there
that
was.
This
may
be
the
first
requirement
across
the
entire
api.
That
requires
you
to
keep
this
memory
and
and
the
idea
of
a
streaming
sdk
was
one
that
simply
records
every
event
downstream
and
then
downstream
pieces
it
all
together
so
yeah.
I
do
oppose
oppose
this,
and
I
I've
been
thinking
about
it.
I
I
haven't,
I
don't
have
an
idea
yet
so
please
continue.
B
I'm
wondering
to
what
degree
this
is.
This
is
a
situation
that's
happening
in
reality,
for
example,
it
sounds
like
one
issue
is:
instrumentation
is
setting
the
span
status
after
the
end.
User
has
access
to
the
span,
so
the
the
last
right
wins
and
its
instrumentation.
B
I
also
wonder
to
what
degree
this
is
an
issue
with
configuration
for
instrumentation
right
is
the
issue
more,
that
the
end
user
is
just
trying
to
configure
like
some
status
codes
or
routes,
to
not
count
as
errors
and
should
be
done
as
configuration
rather
than
telling
them
they
have
to
go
to
their
code
and
do
this.
So
I
just.
F
I
have
a
question:
could
we
have
a
first
right,
wins
rule
and
just
let
everybody
record
status
and
and
say
the
application
wins
in
this
case.
B
You
could
have
the
opposite
problem
in
that
case,
which
is
the
instrumentation
is
setting
the
status
first.
If
it's.
A
B
G
You
can
argue
that
application
is
written
in
goofy
way
that
it
returns
for
400
something
response
code
for
expected
outcome,
but
well
that
that
client
error.
I
can
totally
see
that
well
in
this
particular
case
of
this
particular
use
case
of
the
business
they
want.
They
don't
want
to
count
that
as
an
error
right
so.
B
I
feel
like
this
comes
up
most
commonly
with
status
codes
right
where
we
have
a
default
list
of
like
what
status
codes
count
as
errors,
and
there
is
no
like
one
right
answer
to
that
question
and
the
user
needs
some
way
to
actually
configure
which
status
codes
count.
As
an
error
like
in
general,
like
with
http
instrumentation,
it
seems
like
the
end.
Users
need
a
a
fair
amount
of
configuration
at
their
fingertips.
For
example,
they
also
want
to
silence
certain
certain
requests
altogether.
B
F
Yeah,
I'm
I'm
still
thinking
of
examples.
My
my
example,
I'm
thinking
of
is
the
go
http
service,
which
has
a
right
header
method
and
the
documentation
says
the
first
call
or
right
header
is
the
one
we're
going
to
send
and
you
can't
change
the
header
after
you've
begun
sending
a
body,
so
you
must
decide
your
status
once
before.
You
start
responding
and
that's
that's
just
the
way.
This
is
in
the
protocol
and
I
think
that's
great
and
fine.
F
I
have
a
second
question
I'll,
take
it
off
the
air,
we
don't
what
happens
when
you
call
end
twice
the
first
one
wins
and
I
think
that's
a
there's.
A
the
same
reason
there
is
that
you're,
saying
you're
done
with
something
it's
good
to
say.
You're
done
with
something
only
once
and
I
think
status
and
end
should
be
the
same.
B
So
it's
a
a
little
bit
more
nuanced
than
that.
The
the
okay
was
actually
a
way
for
back
ends
to
differentiate
between,
but
that
was
more
for
back
ends
whether
they
were
trying
to
apply
their
own
schema
or
not.
I
I
guess
what
I'm
saying
is
we
have
okay,
but
you
got
to
presume
that
the
end
user
would
also
want
to
set
error.
B
Maybe
that's
fine,
maybe
you're
right,
maybe
it's
just
the
instrumentation
should
have
a
rule
that
it
should
only
only
change
the
status
if
it's
on
set
if
you've
got
certain
certain
cases
right
like
where
instrumentation
is
trying
to
set
the
status
at
the
end,
you
would
want
it
to
conditionally
set
the
status
right
like
that's.
That's
the
basic
use
case
right
it.
B
You
could
say:
okay,
there's
a
there's,
an
additional
flag
called
like
user,
and
it
says:
oh,
I
only
set
the
status
when
it's
set
to
user,
but
any
way
you
cut
it.
What
we're
trying
to
propose
is
that
at
the
sdk
and
api
level,
there's
some
form
of
conditionally
setting
the
status
that
instrumentation
would
do
right
right.
Does
that?
Does
that
make
sense?
I
think
that's
what
you're
proposing
right
right,
john.
B
Me
I'm
not
proposing
anything
I'm
you're
saying
like
like
like
if
we
were
looking
at
a
way
for
the
back-end
to
differentiate
we're
looking
at
a
way
to
differentiate
between
statuses,
set
by
instrumentation
versus
statuses
that
were
set
by
the
end
user.
B
The
thought
so
far
was
that
this
would
be
something
that
only
back-ends
would
care
about
right,
like
you
could
change
this
status
code
in
the
collector,
for
example,
and
it
was
more
about
the
backend
receiving
that
data
trying
to
decide
whether
it
was
going
to
throw
that
information
away
and
apply
its
own
schema,
because
a
lot
of
back
ends
have
their
own
email
for
what
counts
as
an
error.
Or
did
they
want
to
recognize
that
something
was
actually
from
the
end
user
and
overwrite.
It.
D
Another
option
is
so
for
all
these
things.
When
instrumentation
set
error,
we
have
some
rules
like
http
status,
code
400
or
something
like
that.
We
have
some
rules
where
that
information
is
presented
in
the
spam.
So
what
we
can
do
is
we
can
say
that
status
is
only
for
application
user
and
never
set
by
any
instrumentation
library,
because
you
can
on
the
backend
side,
you
can
apply
the
same
rules
and
derive
that
information.
D
So
so
what
we
can
do
is
simply
say
that
in
the
auto
instrumentation
or
in
any
third
party
instrumentation,
we
never
set
a
status
and
the
back
end
based
on
the
information
that
are
present
in
the
span.
If
the
status
was
not
set
by
the
application,
if
it's
on
set
can
derive
their
own
status.
If,
if
the
status
is
set,
it
means
the
final
user
application
owner
or
whatever
is
called
made
a
decision
on
this.
So
you
stick
with
that.
So.
B
A
B
Because
for
one
systems
rely
on
the
status
code
being
set
today
and
two,
it
was
just
genuinely
baffling
to
end
that
nothing,
nothing
counted
as
an
error.
So.
D
Wait
a
second
we
can
provide,
for
example,
in
the
collector
we
can
provide
the
processor
that
does
this
and
say:
okay,
if
we
see
status
unset,
we
try
to
apply
all
the
rules
that
would
set
the
status
to
error.
So
we
have
a
backwards,
compatible
story
that
you
will
be
able
to
see
in
your
back
and
these.
If
your
backend
does
this
job
for
you,
you
don't
need
to
do
anything,
because
the
back
end
will
will
determine
the
errors.
B
D
Okay,
we
can
still
do
that,
even
in
the
library
I
mean
this
behavior
can
be
done
even
in
the
library
by
by
simply
looking
at
all
the
the
spans
in
our
small
pipeline
that
we
have
between
the
the
sdk
and
the
exporter.
We
have
a
processor,
we
have
we
and
we
can
chain
couple
of
exporters
or
whatever
we
call
them.
We
can
have
a
small
processor
there
inside
that
pipeline,
that
does
that
for
user
and
don't
require
things.
But
still
the
idea
is
the
auto.
D
H
H
I
I
think
I'm
much
more
leading
towards
josh's
idea
of
first
right
wins,
and
then
we
just
provide
guidance
to
instrumentation
that
you
should
only
try
to
set
a
status
on
a
span
immediately
before
you
end
it
that
way.
You
know
you're
the
last
thing
that
tries
to
set
the
status
on
this
span
and
if
the
user
wants
to
override
it,
they've
said
it
before.
B
I
that
does
seem
reasonable.
I
can
see
tricky
situations
where
instrumentation
doesn't
doesn't
have
that
hook.
Unfortunately,
this
is
like
part
of
the
problem.
With
this
whole
mess
is
like
you
know,
well
how
you
attach
instrumentation,
isn't,
isn't
standardized
and
you're
often
left
doing
something
tricky.
I
don't
know,
if
that's
the
case.
G
E
I
I
What
do
you
mean
like
on
end
handlers?
Don't
currently
exist.
B
B
B
E
D
It's
not
gonna
work
for,
for
that
particular
reason.
The
other
option,
by
the
way,
one
thing
that
we
did
in
open
sensors
was
initially
we
allow
status
to
be
set
only
on
the
end
event,
just
because
we
wanted
to
make
sure
that
it's
called
only
once
as
the
the
end
the
span
end.
D
Another
option
is
to
have
this
option
to
set
status
when
you
call
end
on
the
span
and
the
instrumentation
or
third
party
should
use
only
that
method,
not
the
set
status.
D
So
then,
then,
then
we
can
have
if
we
you
have,
if
you
provide
the
status
on
the
end,
call
because
we
have
some
end
options
that
allow
you
to
provide
the
timestamp.
We
can
have
the
status
as
well
in
that
those
options
instrumentations
calls
only
that
so
now.
Hence
we
can
have
a
priority
and
say
if
status
is
said
by
on
end
on
the
end
think
is
lower
priority
than
if
somebody
called
said
status.
B
Do
we
need
do
we
still
need
a
concept
of
knowing
who
set
the
status?
I'm
wondering
if
that's
that's
still
a
thing
we
need,
because
we
could
do.
We
could
do
what
you're
saying
bogdan
and
we
could
also
provide
an
alternative
set
status
method
for
instrumentation
to
use
if
we,
if
we
needed
to
handle
this
issue
more
generally,
in
other
words,
like
we
can
say,
set
status
is
for
end
users
only
and
then
there's
just
a
question
of
do.
We
need
to
have
a
flag
that
lets.
You
know
whether
it
was
like.
B
B
We
could
add
that
later,
in
a
way
that
wasn't
a
breaking
change
by
saying
the
set
status
call
sets.
The
statuses
sets
the
status
source
as
user
and
we
could
add
another
api
call
for
instrumentation
to
use
if
it
needed
to
set
the
status
as
instrumentation
and
then
have
the
sdk
know
that
set
status
by
user
overrides
set
status
by
instrumentation.
B
We
don't
have
to
do
that
right
now,
I'm
just
pointing
out
that
if
we
ended
up
needing
to
add
the
status
source
as
a
concept
like
if
we
end
up
feeling
like
we
need
that
we
can
add
it
in
a
way
that
would
be
backwards
compatible.
So
just
pointing
that
I
mean.
B
Right
so
we
could
just
add
this
onto
on
end.
The
only
just
the
only
reason
I
bring
this
up
is,
I
feel
like
we're
going
to
try
this
and
then
we're
going
to
have
people
come
back
and
say
it's
just
like
not
feasible.
For
me
to
do
this
with
this
piece
of
instrumentation,
because,
like
on
end,
is
happening
in
some
other
place,
where
I
don't
have
access
to
any
information
and
it's
another
thread,
and
I
have
no
way
of
getting
the
information
over
over
there
or
something
like
that.
G
B
G
B
B
B
A
G
G
B
G
G
B
Okay,
does
anyone
oppose
this
plan?
Nikita
is
going
to
do
a
spike,
we're
going
to
see
if
adding
a
status
on
end
a
configuration
option
would
that
doesn't
override
set
status
if
it
was
called
so
this
is
also
a
thing
for
other
maintainers.
B
C
B
Correct
yeah
magical
streaming
sdk.
This
is
sort
of
where
you
have
to
say
first
right
like
in
that
streaming
sdk,
it
would
be
whatever's
receiving
that
stream
data
throws
away
any
additional
span,
statuses
that
come
in.
C
B
A
J
Yeah
thanks
carlos,
so
this
is
a
quick
status
update,
so
the
matrix
api
spec
is
making
progress
and
we
have
two
remaining
issues.
One
is
a
very
subjective
and
the
hardest
topic,
the
naming
of
the
instrumentation.
So
once
we
decided
the
names,
I
think
we
already
have
the
synchronous
and
asynchronous
like
instrument
when
it's
called
counter.
The
other
async
part
is
called
the
counter
func.
J
J
We
can
put
some
effort
just
to
figure
out
the
name,
and
meanwhile
I
I
I'm
feeling
that
the
metrics
api
sig
we're
having
too
many
matrix
experts
like
josh
bogdan
they're,
very
familiar
with
this
topic,
I'm
I'm
probably
the
only
guy
that
that
is
relatively
new
to
the
metric
space.
So
my
ask
is
for
people
who
are
interested
in
the
metrics
but
have
relatively
low
experience.
Please
join
and
give
us
the
feedback,
because
the
we
want
to
find
a
balance.
J
The
name
should
feel
reasonable
to
the
matrix
experts
instead
of
misleading,
but
it
also
should
feel
from
like
should
make
the
customers
that
are
using
existing
metrics
api
like
premises
or
micrometer,
feel
familiar.
Instead
of
you
come
from
a
place
where
something
called
gauge
and
you
move
to
the
open,
telemetry
space,
there's
an
api
called
gauge,
but
they
have
totally
different
meanings.
J
We're
trying
to
find
that
balance.
So
so,
please
join
the
third
day,
metrics
api,
sdk
spec
meeting
and
help
us
to
hammer
out
the
names
and
the
next
topic
we
decided
to
park
it
for
now
and
once
we
finish,
the
sdk
spike,
we'll
come
back,
it's
about
the
hint
api.
So
for
people
who
haven't
heard
about
this,
the
idea
is
when,
when
you
have
a
library
you
want
to
instrument
that
you
want
to
describe.
These
are
my
values.
These
are
my
dimensions,
but
ultimately
you
want
to
make
it
simple
for
your
user.
J
So
if
you
have
something
like
histogram,
you
probably
want
to
suggest
the
user.
These
are
the
bucket
size.
You
want
to
use
instead
of
like
leave
that
entirely
to
the
user
and
let
them
struggle
whether
they
should
pick
a
equal
size
bucket
or
exponential
packet
size,
and
also
you
might
want
to
recommend
hey.
These
are
the
default
dimensions.
You
probably
want,
so
the
user
don't
have
to
struggle.
Oh,
the
library
has
provided
10
different
dimensions,
which
one
should
I
pick
and
there
might
be
additional
thing.
For
example,
you
might
tell
the
user.
J
This
particular
dimension
is
a
higher
technology
one.
So
if
you
want
to
enable
that
you
got
to
be
careful
like
the
the
memory
size
in
your
process
during
the
pre-aggregation
and
the
storage
cost
might
grow
a
lot.
So
these
are
the
things
we
figure
is
very
similar
to
the
isdk
view
concept.
Where
in
the
instrumentation
you
you
basically
give
user
all
the
available
information,
but
the
user
can
in
the
ick,
define
what
they
want.
They
can
say.
J
I
only
want
three
dimensions,
so
we
believe
once
we
figure
out
how
to
do
the
view
part
in
the
ick
we'll
use
the
same
approach
and
just
come
back
to
the
api.
So
far
the
the
timeline
haven't
changed.
So
I'm
I'm
trying
to
see
if
we
can,
we
can
figure
out
the
names
by
end
of
this
week
or
like
early
next
week
and
after
that,
we're
giving
ourselves
six
weeks
to
hammer
the
ice
tk.
Given
we
already
have
a
lot
of
sticks
that
implement
the
ict
based
on
the
previous
spikes.
J
I
I
think
the
majority
of
work
is
just
to
hang
out
the
details
and
make
sure
the
spike
is
really
like
it's
clean,
and
so
people
can
follow
that
and
after
that,
by
end
of
may,
I
expect
we'll
have
the
experimental
release,
which
means
we'll
switch
the
signal.
For
now
we
tell
people,
don't
look
at
the
spike
and
implement
that
across
multiple
languages.
We
only
recommend
people
who
who
are
closely
working
in
this
group
to
do
some
experiments
like
we
select
three
languages.
J
Besides
that
we
don't
want
everything
to
spend
their
cycle
and
then
we
change
the
spec.
They
have
to
change
the
code,
but
by
end
of
may
the
hope
is.
We
can
release
the
spec
as
experimental,
which
is
the
official
signal
we're
saying
hey.
We
believe
this
is
the
core
set
of
features:
we're
not
going
to
change
the
scope
of
this
product,
but
we
might
add
additional
things
or
make
small
changes
and
we
recommend
all
the
language
sex
to
start
planning.
So
this
is
the
heads
up
by
end
of
may.
J
C
I've
got
a
question
around
that
so
for
languages
that
already
have
a
experimental,
metrics
sdk
api
implementation
is
the
expectation
that,
like
for
java,
for
example,
that
we
would
create
a
new
package,
a
new
module
for
the
new
api
and
sdk
and
start
from
the
ground
up,
or
is
the
expectation
that
we
would
rip
down
everything
that
we
have
currently
in
place
and
basically
provide
potentially
the
next
the
1.2
release
for
java,
no
metrics,
no
functional
metrics.
That's
api
and
sdk
at
all.
J
I
I
think,
ultimately,
this
this
depends
on
each
language
sakes,
maintainers
decision
I
can
share
what
like
donate
folks,
had
a
debate,
and
this
is
what
they
decided
to
do
so
in
the
current
release,
like
the
1.0
release,
there's
no
matrix
at
all.
Cgo
has
removed
everything
and
he
created
a
separate
branch
which
is
just
called
matrix
besides
membrane
and
then
matrix
branch
has
all
the
changes
from
membrane.
J
Like
periodically
he's
doing
this,
like
merge
thing
and
in
the
matrix
branch
we
carried
all
the
experimental
thing
from
last
year
and
we're
making
small
changes
to
to
target
that
towards
the
new
metrics
api
spec.
J
So,
instead
of
releasing
yet
a
different
one,
the
idea
is,
you
will
see
open
telemetry
down
at
1.0,
which
is
the
stable
release,
has
no
matrix
and
then
in
parallel
there
will
be
open
telemetry
down
at
1.2.0
preview
or
like
alphabet
or
whatever
cg
decided
to
call
that
and
that
one
will
have
the
experimental
metrics
api
following
the
latest
spec.
C
C
What
I'm
suggesting-
and
you
know
java
right
now-
has
a
1.0
alpha,
metrics
api
and
sdk
implementation,
I'm
just
looking
for
recommendations
on
whether
we
rip
that
basically
stop
publishing
it
all
together
for
right
now
get
rid
of
it
and
delete
it,
which
will
affect
users
who
are
already
using
it
as
alpha
or
whether
we
should
try
to
change
it
in
place
or
whether
we
should
build,
and
I
I
just
I
mean
it's-
we're
in
a
we're
in
kind
of
a
sticky
spot,
because
we
have
published
something
as
alpha
and
people
are
using
it
and
now
we're
going
to
completely
change
it
out
from
underneath
them.
C
J
I
I
hear
you
I.
I
think
this
is
a
a
little
bit
on
edge,
not
belong
to
the
api
sdk
spec,
but
I
I
think
many
sigs
will
have
similar
like
python.
They
already
have
the
metrics
api
and
it
seems
to
be
working
well,
so
I
can
put
a
topic
on
the
thursday
meeting
just
to
get
the
idea
and
see
if
we
can
align
my
my
my
suggestion
is.
J
This
is
a
hard
topic,
because
each
language
is
at
a
different
status
and
they
might
release
the
package
in
many
different
ways
like
you
know
that
there's
a
monolithic
package
for
all
the
signals
in
java
that
might
be
different
packages
for
different
signals.
So
we
might
need
to
use
that
meeting
to
collect
the
status
and
ideas
from
different
people
and
see
if
we
can
find
some
middle
ground.
A
K
K
Thursday,
okay
and
and
the
the
thing
that
I
want
to
make
sure
of,
though,
is
maintainers
show
up
to
that
so
like
we
should
make
sure
that
maintainers
know
we're
going
to
be
talking
about
how
to
handle
the
metrics
api
changes
so
that
they
show
up
at
the
meeting.
So
you
have
your
stakeholders
there.
That's
all!
That's!
K
Okay,
just
want
to
make
sure
that's
clear
right!
So
yeah
I
don't
know
if
we
have
all
the
maintainers
here,
but
the
because
the
maintainers
meeting
was
yesterday.
So,
however,
you
want
to
like.
Let
them
know
that
we're
going
to
be
talking
about
it
that'd
be
ideal.
That's
all
I
wanted
to
do.
J
Okay,
yeah
thanks
for
for
calling
this
out.
So
this
is
what
I
would
do
I'll
add
a
topic
in
the
thursday
api
sdk
spec
meeting
and
I'll
post
the
link
in
the
open
telemetry
slack
just
to
ask
the
maintainers
to
join,
and
I
don't
expect
everyone
to
join,
but
we
should
have
a
reasonable
set
of
people
there
should
we.
F
J
B
Just
riley,
when
you
post
it
on
slack,
I
suggest
posting
it
in
the
spec
channel
and
then
cross
posting
it
in
the
maintainers
channel.
J
A
Perfect,
okay,
I
think
this
is
it.
Thank
you
so
much
guys
back
to
work,
see
you
see
you
later
this
week.