►
From YouTube: OCI Weekly Discussion - 2022-04-14
D
E
D
D
D
So
yeah
we're
five
after
go
ahead
and
kick
it
off
immutable
tags
popped
up
this
week
and
it
seemed
like
an
interesting
discussion,
so
I
figured,
I
would
just
make
sure
it
was
visible
here
in
case
people
had
more
thoughts
on
how
to
discuss
that
kind
of
gets
into
the
question
of
how
do
we
want
to
communicate
this
from
the
person
pushing
the
image
and
the
person
pulling
the
image
with
or
without
registry
support
and
all
the
different
various
scenarios
in
there
and
I
can
kind
of
get
where
akihiro
is
coming
from,
but
he's
just
looking
for
something
he
can
put
into
that
get
some
and
then
he
can
make
client
tooling.
D
D
So
he
was
looking
at
from
the
client
side
where
his
client
could
do
some
enforcing,
but
I
think
all
of
us
are
looking
at
it
from
the
registry
side
of
if
a
registry
doesn't
support
that,
then
what
happens
with
the
client
jason
has
some
good
thoughts
in
there.
Other
people
have
some
good
thoughts
in
there
figured
out
open
up
her
thoughts
in
here.
C
I
just
I
just
got
done
reading
all
the
comments
here.
I'm
wondering
with
the
extensions
idea
is
that
enough
to
enforce.
Is
that
enough
to
say
immutable
tags
are
truly
supported,
whereas
with
jason's
idea
it
seems
to
be
put
a
character,
that's
not
allowed,
and
that
would
be
like
truly
an
indicator
or
maybe
nothing's
a
true
indicator.
D
Yeah
because
xanax
here
came
back
and
said
well,
who
knows
if
a
registry
is
really
filtering
that
out
today,
it
could
just
allow
we
just
don't
know,
because
no
clients
are
doing
it,
and
there
is
a
downside
to
if
you
make
this
switching
here
in
the
tag
and
put
a
new
valid
character
in
there.
That
sure,
maybe
a
registry
can
support
it
right
away,
but
you're
going
to
find
some
clients
out
there
that
don't
support
it.
And
so
now
your
images
aren't
pullable
and
so
that's
a
whole
different
set
of
challenges.
A
Some
registries
already
support
this
like
we
support
immutable
tags
and
acr
today
and
there's
various
places
you
want
to
do
those,
and
I
think
the
idea
of
immutable
tag
is
the
tag
itself
shouldn't
change
right
like
if
I
want
it
to
mutable,
it
might
be,
it
might
be
v
2.2
to
start,
and
it
is
immutable
and
later
I
might
want
to
unlock
it,
so
I
can
update
it
if
there's
a
special
character
in
it.
I
don't
really
know
how
you
do
that.
A
So
I
haven't
read
the
whole
thread
here
and
it's
just
a
the
other
is
a
general
comment,
as
I
worry
about
all
the
the
stuff
we're
trying
to
jam
into
tags
as
opposed
to
actually
improve
the
specs
to
say
here's.
What
a
registry
supports.
There's
a
I
forgot,
what
we
called
it.
Basically,
an
api
that
says:
here's
what
version
the
registry
is
and
what
capabilities
a
capabilities
api,
that's
what
it
was.
So,
yes,
I
love
immutable
tags.
We
support
it,
we
implement
it.
I
know
some
others
do.
D
And
I
see
brian's
comment
that
if
it
was
really
immutable,
you
would
use
a
digest.
Yes
and
no,
I
can
see
some
value
for
having
a
tag
that
can't
be
changed,
but
I
also
get
that
if
you
want
something,
that's
truly
immutable.
The
digest
are
the
way
to
do
that
today.
A
Yeah,
I
think
the
balance
there
is
two
things
one,
it's
kind
of
what
I
was
just
saying
before
in
a
sense
that
immutable
locking
is
truly
immutable.
Is
yes
it's
a
digest,
but
it's
not
human,
readable.
There's,
there's
something
to
be
said
about.
I
can
look
at
something
and
mentally.
Remember
it
when
I
see
it
in
a
kubernetes
listing
or
otherwise,
but
it's
also
the
ability,
if
it's
a
tag,
that
is
that
you
can
unlock
it
and
fix
it
like
truly.
A
Truly,
I
don't
you
know
if
you
truly
truly
want
to
make
it
always
immutable,
you
could
just
leave
it
locked
and
maybe
there's
a
part
of
this
immutability
api
is
there's
a
the
tag.
History
api.
There
was
an
interesting
conversation
that
docker
actually
implements
that
so
when
they
do
their
deletes.
D
Yeah
and
that
kind
of
jumps
into
my
comment
of
what
happens
if
you
delete
it,
does
the
delete
fail,
and
so
now
you
have
content
that
you
can't
get
rid
of.
Does
the
delete
succeed
now
it
can
be
replaced
with
something
new,
or
do
you
not
keep
track
with
the
tag
history
like
you're,
saying
to
know
that
this
was
previously
a
deleted
tag
and
the
only
thing
it
can
get
put
back
with
is
this
specific
value.
A
Are
you
saying
that
immutability
means
locking
as
well
there's
actually
two
there's
like
delete,
lock
and
update
lock
was
the
way
we
think
about
it
in
acr.
D
Yeah-
and
I
don't
think
that
was
defined
in
the
spec
of
which
we
were
looking
at
until
until
I
asked
the
question,
I
think
he
came
back
and
he
might
have
updated
the
other
direction
I
was
taking.
We
were
mentioning
maybe
some
of
the
extension
fields.
I
was
also
wondering
if
it
made
sense
to
maybe
extend
the
tag
listing
api
itself
and
so
you're
not
looking
at
the
tag
name,
but
something
in
the
tag
listing
api
could
tell
you
hey.
This
registry
supports
immutability,
and
this
tag
here
that
has
returned
to
you
itself
is
immutable.
D
D
D
Which
is
we're
kind
of
getting
to
the
point
of
the
working
group
that
I
feel
like
we're
consolidating
around
one
of
our
proposals?
We
had
a
b
c
and
d
and
each
one
of
them
had
different
values
that
we
were
bringing
to
the
table
and
then
proposal.
He
said.
Let
me
cherry
pick
a
bunch
of
ideas
from
a
bunch
of
them
and
put
them
all
together
into
one
big
proposal,
and
so
the
result
there
I'm
actually
going
to
open
this
up
as
a
new
file.
D
Which
is
probably
what
josh
linked
to
over
there
as
well
yeah,
so
this
kind
of
goes
through,
and
there
are
some
things
that
I
haven't
gone
through
an
update
we
were
chatting-
and
this
is
right
now-
it's
very
rough
around
the
edges.
It's
just
a
proposal,
it's
not
like
a
formal
spec
or
anything
just
yet,
but
it
does
add
a
new
media
type
and
so
we'll
have
me
a
type.
That's
for
just
artifacts
that
contains
just
blobs.
D
D
It
defines
a
couple
annotations
for
filtering
things
and
it
defines
an
api
that
we
want
to
add
to
the
distribution
spec
for
how
we
can
extend
this
stuff,
and
so
with
that.
The
goal
of
having
all
these
things
working
together
is
that
we
actually
have
a
forward
progress,
some
kind
of
some
kind
of
way.
We
can
start
now
with
what
we
have
out
there
with
registries
today,
but
also
have
that
forward
value.
D
As
we
start
getting
registries
to
upgrade
and
clients
to
upgrade,
we
can
make
make
use
of
that
new
value
so
registries
a
day
without
the
api.
They
can
just
push
some
digest
tags
up
there,
similar
to
what
you
see
out
of
cosine,
how
they
were
doing
it.
They
have
their
little
digest,
I'm
adding
into
that
a
a
hash
field
in
there.
So
you
can
push
multiple
of
these
concurrently
and
so
they're.
D
Not
you
don't
have
to
worry
about
maintaining
index,
they
can
all
go
together
and
then,
once
that
is
out
there
you're
pushing
image
specs,
so
that
should
just
be
accepted
by
registry.
A
tag
should
just
be
accepted
by
retreat.
So
we
can
do
this
today.
Only
thing:
that's
holding
us
back.
D
It's
just
us
agreeing
that
that's
what
you
want
to
do
and
then
once
registry
start
to
upgrade,
then
you
can
start
using
the
new
api,
but
since
you've
made
an
image
that
is
being
passed
around
for
the
actual
data
that
same
image
that
is
pushed
to
a
registry,
it
has
the
new
api
that
you
can
query
can
also
be
pushed
to
a
registry.
It
doesn't
have
the
api
and
just
use
the
tag,
and
so
you
have
that
portability
from
registry
to
registry.
D
The
object
is
identical,
it
doesn't
change
the
digest,
states
its
thing,
and
so
you
get
that
portability
in
there
and
then,
once
all
registries
do
update,
then
you
can
say
great
we're
to
this
new
good
point.
We've
got
an
api
out
there.
We
can
query.
We've
also
got
this
new
media
type
and
let's
start
using
the
media
type
for
things,
because
they
might
want
some
value.
Out
of
that,
you
want
to
push
a
separate
image
config
in
addition
to
your
image
layers,
there's
some
value
coming
out
of
that.
D
So
that's
kind
of
what
this
does
just
want
to
give
you
an
idea.
This
was
coming
a
lot
of
stuff
to
read.
I
don't
know
if
you
want
to
see
me,
go
through
the
whole
presentation,
a
second
time,
because
I
was
already
doing
a
working
group
earlier
this
week.
My
main
goal
here
was
just
to
say:
this
is
coming
we're
going
to
probably
formalize.
It
tweak
up
a
couple
things
that
are
missing
in
here
and
I
just
wanted
to
open
it
up.
D
For
q,
a
from
general
oci
side
of
are
there
things
you
want
to
see
coming
out
of
this?
Do
you
want
to
make
sure
that
we
don't
miss
a
short
detail
all
in
those
lines,
or
do
you
have
questions
and
wants
to
go
back
and
revisit
our
whole
thought
process.
C
I
think
that
I'm
I'm
glad
that
you
put
together
something
like
I
said
in
the
other
meeting,
that
sort
of
spans
the
registries
with
no
support
to
the
end
of
the
spectrum
and
with
the
upgrade
path.
So
I'm
hopeful
that
this
with
some
feedback
will
get
us
to
the
finish
line
of
the
working
group.
D
D
D
Let's
see
other
than
that,
the
new
media
type
looks
very
similar
artifact
manifested
image
manifest.
It's
gonna
have
a
list
of
blobs.
It's
going
to
have
the
reference
field
annotations,
but
no
config
and
the
blobs
are
not
necessarily
ordered
they're
optional
as
well.
So
this
lets
you
get
a
lot
more
lean
in
the
artifacts
side.
D
For
the
api
just
swapped
out
phone
to
manifest
with
porno
reference,
and
then
you
query
with
your
digest
and
then
you
get
back
image
index
or
index
so
an
array
of
manifest-
and
these
are
just
all
the
different
things
that
refer
to
that
reference
that
you
gave
it,
and
so
you
say
I've
got
this
image
out.
D
There
tell
me
everything
points
to
it
and
it
comes
back
and
says
here
the
three
different
artifacts
that
point
to
that
image:
presents
it
to
you
in
it
in
an
index
and
we'll
pull
up
the
annotation,
so
whatever
annotations
they
put
on
that
artifact
will
pull
it
up
to
this
level.
So
you
can
do
any
other
filtering
or
querying
there,
but
we're
also
going
to
introduce
a
filtering
api
as
well.
So
you
can
do
server-side
or
potentially
client-side
filtering
whatever
makes
the
most
sense.
D
Still
a
little
bit
of
discussion
on
how
we
want
to
set
up
this
api,
I'm
thinking
more
than
just
like
an
equal
value,
I
probably
have
like
some
greater
than
less
than
we'll
have
some
sorting,
both
ascending
and
descending
sorts.
So
I
need
to
work
that
out
a
little
bit
more
can't
just
be
a
simple
equal
right
there,
but
yeah
that's
kind
of
the
things
we're
thinking
of
in
terms
of
we
want
to
query.
Give
me
the
newest
scan
result.
That
has
you
know
the
most
recent
date
field.
D
D
And
then
for
anybody
that
hadn't
seen
the
digest
tags,
they
have
the
algorithm
so
shot
256
the
reference
that
you're
pointing
to,
and
so
this
would
be
like
your
image,
digest
a
short
hash
of
the
artifact
that
you're
actually
that
this
tag
points
to,
and
so
this
is
going
to
be
say
your
signature.
This
will
be
a
short
hash
of
that
signature
digest
and
then
what
it
is.
D
So
in
this
case
I
had
s,
bomb
could
be
signature,
have
a
couple
short
things
here
that
people
would
be
like
some
well-known
extensions
people
could
query
on,
and
this
is
kind
of
our
intermediate
state.
This
is
what
will
work
today
with
the
registry,
and
then
the
goal
is
to
get
registries
upgraded.
So
we
can
get
off
of
this.
D
The
idea
behind
having
that
hash
there
is
that
deduplicates,
you
can
push
a
whole
bunch
of
these
references
all
to
a
same
image
out
there
and
they
don't
collide
with
each
other.
So
you
have
the
ability
to
do
multiple.
These
pushes
lots
of
signatures,
lots
of
scan
results
without
having
to
worry
about
ordering
or
any
other
collision
issues
like
that
you're,
not
no
race
conditions,
what
I'm
thinking
of-
and
that
is
pretty
much
it
that's
worth
thinking
of.
D
Got
a
quiet
group
out
there
today
any
any
thoughts
on
things
that
we
should
be,
including
when
we
bring
this
up
to
the
greater
oci.
I'm
assuming
we're
gonna
have
like
a
a
pull
request
to
image
spec
a
pull
request
to
distribution
spec
and
if
we're
introducing
a
new
media
type
should
that
be.
Is
that
going
to
go
into
image,
spec
repository
or
should
that
go
into
a
different
repository,
all
its
own
or
an
artifact
spec?
And
we
just
make
a
new
new
section
over
there
redefine
what
artifact.
A
Maintainer,
I
would
just
suggest
the
goal
is
always
to
get
this
the
distribution
spec.
So
I
don't
want
to
make
it
yet
another
like.
If
I
would,
I
would
put,
I
would
suggest
distribution
spec
would
be
the
best
place
for
it
and
merge
what
we
have
an
artifact
spec
in
the
distribution,
but
just
from
an
artifact,
spec,
maintainer
or
artifacts
repo.
Whatever
we
call
it.
C
My
this
is
just
my
thoughts.
My
idea
with
the
template
is
the
breakdown
in
the
changes
section.
C
C
A
This
this
goes
back
to
the
refactoring
conversation.
We've
been
having
for
a
long
time.
There's
the
the
image
spec
the
run
container
runtime
spec
folks
should
have
a
place
that
they
could
innovate
in
the
places
that
they
need
to
do,
uniquely
to
them
to
put
the
burden
on
them
that
they
have
to
carry
the
generalization
for
all
artifacts
is,
I
think
it's
just
un
untenable.
So
the
idea
is
that
the
artifact
spec
has
the
generalization
that
can
support
any
artifact
type
and
the
image
spec
can
say
just
like
the
helm
team
right.
A
The
home
team
takes
the
basically
the
oci
artifact
proposals,
the
the
model
of
what
oci
artifact
is
and
defines
how
they
use
it
and
all
the
other
artifact
types
that
use
it
as
well.
So
the
idea
is,
let's
kind
of
continue
down
that
path.
A
A
A
A
And
then,
just
like
the
helms,
the
basically
the
image
spec
becomes
similar
to
the
helm
spec
it
is.
This
is
how
this
particular
artifact
type
uses
it
and
what
it
does
uniquely
to
it,
and
you
don't
have
to
worry
the
image.
Spec
maintainers
can
worry
about
the
container
runtime
image
format
and
they
run
with
that.
D
A
Evolving
the
image
spec.
I
think
you
put
that
in
the
image
spec
I
mean.
That
would
be
my
suggestion.
I
I
don't
you
know,
I
think,
we've
the
idea
of
refactoring.
You
know
some
of
this
stuff
has
so
much
friction
that
it's
not
worth
it
in
some
places.
If
you're
don't
break
what
exists,
I
think
there's
a
huge
version
in
question
related
to
adding
schema
to
this
manifest,
but
I
think,
if
you're
going
to
build
a
new
manifest,
it's
the
place
that
you
actually
fix
it.
D
A
A
D
I
define
breaking
you're
adding
me,
I
have
a
runtime
and
I
see
a
schema
version-
that's
not
to
right
now.
I
don't
know
what
to
do
with
that
object.
I'm
not
going
to
be
able
to
work
with
it
and
the
whole
goal
of
putting
a
field
in
there.
That
was
just
an
unknown
field
was
that
I
wouldn't
have
to
modify
any
existing
runtimes
to
make
this
work.
D
B
D
B
It
depends
if
you
want
the
the
way
distribution
distribution
is
written,
is
based
on
the
the
value
of
schema
version,
equals
two
and
then
a
set
of
schema
types
for
that
version
right.
So,
if
you
wanted
to,
you
know,
create
some
new
schema
type
to
be
able
to
process
additional
fields.
Then
then
you
know
we
could
do
that,
but
it
would
be
a
new
schema
type.
Now,
if
you
need
a
new
version,
that
would
be
presupposing
some
different
set
of
schema
types.
B
D
My
big
goal
of
being
able
to
say
extending
the
image
manifest
with
this
one
new
field
got.
It
was
that
per
the
extensibility
requirement.
They
said
that
should
just
be
okay
and
then
once
we
get
to
okay,
we
want
to
redefine
what
these
fields
look
like
right.
Then
we
need
a
new
media
type
and
we
need
to
make
sure
that
we
support
that
right,
and
so
that's
why
we're
going
to
have
a
lot
of
time
until
that
happens,
yeah.
B
In
in
theory,
as
long
any
new
additional
fields
will
just
get
stored
right,
they
won't
be
processed
as
new
as
new
types.
If
you
needed
additional
functionality
based
on
the
type,
then
we
then
we
have
to
move
the
media
type
version
up
and
create
a
new
schema
right,
resolver
in
distribution
distribution
to
handle
that.
D
So
the
new
functionality
is
only
going
to
be
on
registries
that
support
the
new
api,
and
so
the
idea
here
is,
if
you
query
the
registry,
the
api
comes
back
404.
I
don't
know
what
you're
telling
me,
but
then
that's
okay,
but
if
the
registry
does
have
the
api,
then
it
should
use
this
to
populate
the
contents
of
whatever
response
that
api
is.
Can.
B
That's
interesting,
I
I
mean
yeah.
I
don't
really
see
a
problem
with
that
I
mean
you
could
always
just
add
more
code
for
b1.
If
you
see
the
new
field
then
switch
on
that
behavior
right
and
then
the
old
code
that
doesn't
know
that's
there,
it
wouldn't
work
but
you'd
have
to
modify
the
old
code
and
that
therein
lies
the
problem
right.
If
you're
expecting
a
different
behavior.
D
Well,
the
the
idea
is
that
the
old
code
with
the
current
behavior
is
right,
and
so
it
shouldn't
change
any
behavior
of
the
old
code.
The
only
place
this
reference
gets
used
is,
if
you
have
the
new
api
and
that
api
says,
let
me
find
everything
that
has
that
field
defined
and
if
the
field
didn't
define,
then
greatly.
B
Got
it
that
makes
sense,
especially
after
we
we
add
the
new
api
for
getting
a
list
of
the
extensions
and
such
right
yeah,
okay,.
D
B
D
A
Bingo,
I
I
guess
I'm
not
suggesting
it's
schema
version.
12.,
I'm
wondering,
is
it
2.01?
Is
it
like?
There
is
a
difference
in
the
schema,
and
I
just
and
I
I
get
the
media
type
and
that's
been
always
my
struggle.
Is
the
media
type
and
the
schema
version
you
know.
So
I
look
I
we
we
can
we've
already
implemented
it,
so
I'm
not
overly
worried
about
it
per
se.
I
just
I
worry
about
what
is
what
are
we
setting
as
expectations
for
the
for
the
community
for
how
we
ship
specs.
D
To
me
it
it
just
solidifies
the
extensive
requirement
of
what
we
expect
from
that
extensibility
requirement,
which
is
hey.
We
didn't
change
anything.
You
already
knew.
We
only
added
an
additional
field,
and
if
you
completely
ignore
that
additional
field
and
no
not
don't
know
what
to
do
with
it,
you'll
still
behave
correctly.
A
D
B
A
E
A
It
gets
tagged
which
is
kind
of
different
problem,
but
it
at
least
satisfies
the
typical
scenario
where
untagged
manifest
have
they're
not
written
in
the
spec.
I
realize,
but
it's
it's
a
pattern
that
we
want
to
make
sure
it
doesn't
get
broken.
So
your
idea
is
that
it
doesn't
know
not
to
delete
it
because
it's
got
a
reference
to
something
that
has
its
own
life
cycle,
but
it
has
an
independent
life
cycle
because
it
has
a
tag.
D
B
D
That's
the
goal.
You
you
query!
The
registry.
You
see
the
ap
api
doesn't
exist.
You
go
okay,
great
I'll!
Just
push
my
digest
tag
up
the
person
doing
the
query
says:
hey
I
just
pulled
out
image00
tell
me
everything
has
got
one
of
these
tags
that
has
that
prefix
to
it
and
then
I'll
just
go
pull
those
back
and
do
what
I
need
to
do
on
the
client
side.
B
D
I
don't
know
if
we
still
have
those,
but
I
saw
that
you
could
buy
a
pack
of,
I
think
ten,
three
and
a
half
inch
discounts
for
twenty
dollars
the
other
day,
guys.
B
D
If
you
do,
we
can't
hear
it
feel
free
to
jump
in
anytime
all
right,
so
my
go-to
other
than
clean
this
up,
because
we
still
have
stuff
to
finish
up
here,
is
to
get
some
pull
requests
at
some
point.
Once
we
finish
up,
you
know
we're
not
done
with
this
in
the
working
group,
but
we're
getting
close
before
we
bring
to
oci
is
just
to
come
up
with
some
poor
requests,
mostly
on
distribution,
spec
and
then
we'll
also
add
in
a
couple
small
ones
for
this
one
field
on
image,
spec.
A
That's
another
angle
of
the
versioning
thing,
because,
basically,
if
you're
sticking
it
there
you're
effectively
saying
there
is
a
new
version
of
the
registry
spec
as
opposed
to
what
was
nice
with
the
dish
with
the
extensions
api,
is
you
can
opt
into
specific
extensions
kind
of
like
phone
capabilities?
Not
all
phones
have
the
same
capabilities,
but
you
you
there
is
a
common
way
to
define
them,
so
this
was,
if
you
put
it
there.
I
think
this
also
raises
the
question
is
a
version
of
distribution,
which
is
also
find
a
version.
A
A
D
So
considering
the
different
options
there,
one
of
the
thoughts
on
this
one
just
having
it
in
the
normal
path
there
was
it
kept
things
looking
similar
to
what
we
already
have
with
pulling
up
manifest
and
stuff
like
that,
but
you
can
always
define
all
the
http
status
codes
to
know.
Does
this
exist
and
so
the
default
404
comes
back.
You
just
know:
okay,
this
isn't
there,
it
doesn't
doesn't
work
or
we
can
have
stats
goes
to
come
back
and
say
you
know
here.
D
A
You're
assuming
the
new
registry,
I
rent
an
old
registry
yet
provided
that
update
to
say
they
don't
and
they
already
don't
support
it,
because
I
thought
that's
that's
kind
of
the
ability
of
the
just
the
extension
api.
You
can
still
call
an
extension
api
and
if
it
doesn't
exist,
you
still
get
the
404.
A
But
if
you
so
do
you
think
if
you
add
that
to
the
root
like
you've
done,
does
the
distribution
spec
get
version
and
what?
If
so,
does
a
registry
declare
what
version
it
supports
and
if
there's
another
api
that
got
added,
but
I
made
this
optional
for
some
reason,
I
don't
want
to
support
that.
I
don't
know
why,
but
we.
D
D
I
would
bump
the
minor
version
on
distribution
spec,
but
the
idea
of
putting
it
under
the
path
was
that
it's
something
that
shouldn't
resolve
today,
because
if
you
try
to
hit
this
path
today,
there's
no
way
to
come
for
this
structure.
You're,
always
looking
for
like
a
tags
list
or
manifest
something.
B
D
Yeah,
my
my
thought
of
the
minor
version
bump
and
distribution
was
just
hey
if
you
want
to
say
you're
compliant
with
the
latest
version
of
distribution
spec.
You
might
not
have
this
so
you'll
just
tell
people
hey,
we
support
distribution,
spec
1.1,
and
they
know
that
that
means
you
don't
have
these
new
features
in
your
registry
and
when
they
say
we
support
1.2,
then
users
will
expect
okay,
great
I've
now
used
the
new
artifacts
over
there.
That
just
gives
the
users
the
feedback
they're.
Looking
for
of.
B
D
D
Cool,
that's
what
I've
got
any
other
questions.
I
think
a
lot
of
people
have
been
on
the
other
calls
already,
and
so
I
think
that
the
two
big
key
players
here
mike
and
phil
anything
from
your
sides
that
you
want
to
see
out
of
us.
Otherwise,
I
think
we're
on
a
good
spot.
D
Have
a
great
rest
your
day
and
rest
your
week,
we'll
chime
back
in
on
this
one.
We
have
something
ready
to
present,
so
it's
good
thanks
thanks.
Everyone.