►
From YouTube: [OCI-WG] Reference Types - 2022-02-01
B
E
C
Yeah,
oh
okay.
In
that
case,
let's
actually
get
started.
C
I
was
sort
of
like
lightly
waiting
for
someone
to
all
right,
great
welcome
everyone
to
the
meeting.
I
completely
knew
that
I
would
be
leading
josh.
Do
you
have
an
update
on
documenting
the
generic
scenario.
E
Indeed,
I
do
not,
but
I
saw
there
was
a
document
where
we
were
listing
a
bunch
of
requirements
and
I
I
don't
know
if
it
was
lockheed
or
nisha,
but
that
was
written
down
there.
So
I
figure
we
can
pr
that
in
at
the
right
time-
or
I
can
do
it,
I
can
just
do
it
separately
from
that
document
yeah
here
it
is
so
framework
for
discussions.
E
D
It
was
me,
I
guess
no
one
got
that
reference
liar
liar
when
he
goes
when
he
goes
into
the
elevator
when
he
comes
out
of
the
elevator.
E
I
just
I
heard
a
strange
voice
and
I
I
didn't
I'm
sorry.
Okay,
I
I
will
add
this
plus
the
actual,
like
the
actual
profiles
for
the
different
people
into
the
repo.
Does
anybody
have
opinions
on?
D
Yeah,
so
it's
not
visible
here,
but
I
asked
the
question
if
we
were
to
convert
the
user
stories
into
something
that
references,
glenn
and
larry
and
lucky
suggested
that
we
do
that
after
we
solidify
the
user
stories.
So
I
I
think
it
is
basically
queued
up
behind
cleaning
up
the
user
stories.
D
C
Okay,
so
yeah
josh.
I
think
it's
useful
to
add
to
the
repo.
I
don't
think
anybody
has
a
strong
opinion
about
where
right
now,
but
I'm
sure
someone
will
find
one
when
you
propose
it.
So
you
know,
but
after
after
this,
after
we
go
through
some
of
these
user
stories,
I
think
that's
the
like
main
event
here
after
we
go
through
some
of
these,
we
can
settle
on
the
general
scenario.
Does
that
sound
right.
C
Cool
all
right,
I
think,
unless
anybody
has
a
better
idea,
because
I'm
not
sure
how
this
is
actually
gonna
work
in
the
time
that
we
have
here
today,
I
so
when
I
went
through
it.
I
didn't
look
through
it
until
like
two
days
ago
or
maybe
yesterday
and
by
then
all
the
good
ones
had
been
taken.
So
nice
work
everyone
for
taking
all
the
good
ones,
but
what
I
think
I
was
able
to
do
constructively
was
to
sort
of
start
clustering
them
together.
C
I
think
it
could
be
useful
to
go
through
them
and
try
to
cluster
them
more
or
argue
for
why
they
not
they
need
to
not
be
clustered
or
you
know,
sort
of
clustered
cluster
them.
There's
a
ton
of
comments,
and
I
don't
know
if
we
will
be
able
to
get
through
any
of
them.
Some
of
these
don't
have
comments,
and
I
think
that's
a
good
signal
that
we
know
that
that's
one
we
want
so
yeah.
I
guess.
C
Unless
somebody
disagrees,
I
think
we
should
just
go
through
and
see
see
when
the
food,
the
food
fight
starts
as
a
user.
I
want
to
store
signature
and
s
bombs
in
a
registry,
along
with
a
reference
to
the
container
images.
It
is
for
this
one
feels
like
cheating.
Frankly,
this
is
exactly
what
we're
here.
For
so
does
anyone
have
any
clarifying
additions,
edits.
F
F
It's
definitely
user
story.
I
think
we
capture
other
places
where
it's
not
necessarily
an
image
that
we're
adding
a
reference
type
on
top
of
okay,
I'm
going
to
make
this
yeah
attempt
to
say
leave
it,
as
is
because
that
is
a
user
story,
and
it
might
just
be
a
more
generic
user
story
that
comes
out
as
well.
F
H
Oh,
I
wanted
to
probably
give
some
backstory
about
the
discussion
that
lucky
had
about
this.
So
one
of
the
things
he
was
roughly
mentioning
was
that
we
stuck
to
start
with
containers
and
not
go
with
something
generic
like
artifacts,
because
it
makes
it
a
little
more
grounded
and
it
is
oci
which
is
open
container
initiative
sure.
H
So
if
there
is
any
statement
or
comments
that
kind
of
like
pertaining
to
why
we're
using
containers
as
a
start
point,
it's
just
about
defining
the
user
story
and
just
to
keep
people
grounded
in
terms
of
what
we're
trying
to
achieve.
I
think
that
was
an
interesting
takeaway
that
I
had
when
he
kind
of
mentioned
it
to
me
so,
but
he
couldn't
represent
be
here
to
represent
that
point
in
the
meetings
I
just
want
to
share
it
with
the
audience.
C
Yeah,
that's
a
very
good.
Thank
you!
Thank
you
and
absolutely
thank
lucky
also
for
that
simplification.
I
think
that's
actually
going
to
be.
I
will
remove
it
from
here
and
just
make
a
general
note.
C
C
Some
some
artifacts
too
okay,
yeah
great-
I
won't
bother
going
through
and
making
all
of
them
not
say
container
image,
because
I
think
that
actually
will
be
non-helpful
vanessa
also
had
the
same.
The
same
comment
in
the
chat:
okay.
As
a
user,
I
want
to
query
the
registry
for
signatures
for
a
container
image
by
name
and
tag.
I
think
oh
yes,
this
is
me.
C
I
think
we
want
to
a
few
of
these
mention
name
and
tag,
and
I
think
we
should
try
to
be
clear
that
what
we
mean
is
by
digest,
like
I
want
to
store
signature
s
bom
et
cetera
in
a
registry,
along
with
a
reference
to
the
container
image
by
digest,
would
be
my
signat.
My
my
suggestion
here.
Does
anybody
think
that
we
should
support
that?
Not
that
nisha?
Are
we
voting
or
are
we
commenting?
Nisha
had
her
hand
up
first.
D
D
Maybe
a
better
description
is
just
name.
C
I
think
that's,
I
think,
you're
a
few
things
fall
out
of
that.
For
me,
one
is,
I
think,
it's
a
useful
point
to
note
that
a
tag
is
a
kind
of
a
kind
of
reference
right.
It's
a
it's.
A
a
single
string
very
narrowly
allowed
value,
pointing
at
a
digest
saying
this
means
latest.
That
is
a
reference
of
like
latest.
Is
this
or
like
b123
is?
Is
this
I
think
that's
useful
to
write
down
because
I
think
it
might
be
useful
later?
C
I
think
the
name
and
tag
tuple
is
intended
to
mean
repository
image,
name
and
optional
tag
where
the
default
is
latest.
Is
that
how
anyone
else
is
reading
it
or
not?
Reading
it,
okay,
brandon's
giving
me
a
thumbs
up,
you
are
also
next
in
line.
Did
you
also
have
a
comment
on
that
on
that
line.
F
Yeah
my
comment
was
going
to
be
that
calling
it
the
reference
and
tag
yeah,
that's
kind
of
what
I
think
we're
going
toward
and
the
user
story
is
that
they
are
going
to
call
it
probably
more
than
half
the
time
as
much
as
we'd
like
everybody
to
deploy
everything
by
digest.
F
They
are
going
to
call
it
with
a
name
and
a
tag
or
a
repository
and
a
tag,
and
so
that's
the
user
story,
how
we
implement
it
and
how
it
gets
implemented
under
the
covers
that
everything
is
going
to
be
by
digest
or
descriptors
that
that's
our
decision.
But
the
user
story
is
still
going
to
be
by
the
by
the
name.
C
Gotcha,
I
I
also
agree
with
you:
vanessa
had
her
hand
up
and
then
put
it
down,
which
might
mean
agreement.
A
So
my
comment
when,
when
the
early
discussion
was
going
toward-
oh
yes,
we're
going
to
be
querying
by
digest.
My
question
is
okay.
What
is
the
actual
use
case
where
someone
is
like
is:
has
a
digest
handy
and
most
of
the
time
people
have
name
and
tags,
but
it
sounds
like
we've
kind
of
converted
or
converged
on
the
idea
that
we
are
doing
names
and
tags.
You
know
like.
G
A
C
Yeah,
I
think
I
think,
what
you're
saying
and
what
my
comment
was
getting
at
and
what
brandon
is
saying
are
all
in
general
agreement,
which
is
like
the
user
story
is
I
have
ubuntu
at
latest
or
ubuntu
colon
latest,
and
I
want
to
know
what's
in
it
or
I
want
to
know
what
signed
it
or
whatever.
So
that's
the
user
stories.
C
I
want
that,
but
the
implementation
of
how
we
do
that
is
not
necessarily
one
request
like
it
might
be:
look
up
the
digest
and
look
up
things
referencing
that
digest
and
that's
okay
for
us,
which
is
good,
because
that's
probably
what
we're
gonna
do
so
yeah.
I
think
we're
all.
I
think
we're
all
in
agreement.
I
will
add
that
text.
A
Yeah,
this
might
be
a
general
note,
since
we're
talking
about
like
actual
user
stories.
Is
this
someone
that
is
using
the
api?
Are
they
in
a
web
interface?
What
is
what
is
going
on
here.
C
I
don't
think
we
have
laid
out
which
one
it
is.
I
think
we
should.
Some
users
will
interact
with
this.
Well,
almost
no
real
user
will
interact
with
this
via
api.
Some
most
will
probably
use
the
cli
or
ui.
C
I
would
guess
that
the
cli
are
going
to
be
along
the
lines
of
like
docker
type
clis.
There
are
a
few.
There
are
a
bunch
of
non-docker
clis
for
interacting
with
registries.
Uis
are
probably
going
to
be
each
of
their
cloud
like
repository
host.
F
Yeah,
I
think
I
was
one
of
the
few
people
that
actually
started
specifying
as
a
tool
writer
to
describe
the
person,
that's
interacting
directly
with
the
api
and
writing
some
of
the
tools
that
any
users
will
be
using,
and
so
there
might
be
an
option
to
add
an
extra
delineation
there
in
our
stories,
because
I
was
interpreting
users
like
the
end
user
yeah,
I
didn't
care,
doesn't
care
about
the
apis.
They
just
want.
They
just
want
the
data
out.
C
Yeah,
I
think
the
the
tool
author
persona
is
in
general,
in
service
of
a
user
is
in
general,
like
a
proxy
for
the
user,
where
to
some
extent
like
if
it's,
if
it's
possible,
to
serve
this
user.
This
year's
this
user
story
with
really
complicated,
really
flaky
really
buggy
code.
That
does
not
help
the
tool
author,
but
does
help
the
user.
So
we
should
try
to
do
it
so
that
it
helps
both
of
them
together
and,
I
think
we're
I
think
we're
going
to.
C
C
I
think
I'm
going
to
resolve
this
and
hide
discussion,
because
I
think
we've
agreed
on
that
john
has
a
comment
on
the
next
one.
I
think
along
the
same
lines
of
name
and
tag,
probably
same
answer
is
people
will
look
it
up
by
look
it
up
by
name
and
tag
to
get
the
digest
and
then
look
up
the
things
based
on
that
digest,
all
of
all
of
which
will
be
abstracted
away
by
the
ui
or
the
tool
tools
in
front
of
registries
to
the
user.
John?
Does
that
sound
okay
is
johnny.
G
C
Same
thing
I
think
nisha
is:
are
you
also
satisfied
with
our
our
general
agreement?
Point.
D
Yeah,
this
is
no
wait
hold
on
hold
on,
so
this
is
different
right.
This
is
querying
the
registry
for
not
container
image,
but
for
signature
and
s-bombs,
are
we
querying
by
signature
and
s-perm
name
and
tag,
or
are
we
querying
by
container
image
name
and
tag.
C
I
think
the
what
I'm
about
to
say
is
not
authoritative
or
or
an
answer
that
everyone
necessarily
agrees
with.
I
think
the
one
possible
approach
we
could
do
to
solve
this
is
to
say
if
you,
as
a
user,
are
interested
in
all
of
the
signatures,
ask
bonds
etc.
Attached
to
this
image,
you
can
do
that
via
tools
via
uis,
easily
and
efficiently
that
tool
and
that
ui
might
make
multiple
http
requests
might
make
it
request.
First
to
say:
ubuntu
colon
latest
means
sha256
abc
and
things
attached
to
abc.
C
Are
you
know
this
blob
of
things,
but
I
don't
think
we
I.
I
think
the
only
remaining
ambiguity
is
around
the
name
and
tag
phraseology.
Brandon
was
next,
but
also
I
was
answering
nisha's
question.
So
if
either
of
you
want
to
go.
F
C
D
Just
a
general
thing:
I've
noticed
that
a
number
of
user
stories
are
some
permutation
of
this.
Perhaps
perhaps
we
have
to
go
look
at
those
before
we
come
back
to
this
one,
I'm
okay
with
like
you
know.
If,
if
someone
wants
to,
you
know
organize
their
artifacts
by
s-bomb,
then
they
may
want
to
tag
their
s-bomb
and
then
ask
you
know
I
have
this
s-bomb.
What
container
images
does
it
refer
to?
D
That's
a
that's,
a
valid
user
story
and
I
think
it
is
written
some
and
I
think
it's
like
duplicated
somewhere
down
there.
I
know
how
you
want
to
deal
with
duplic
dupes,
jason.
C
F
D
Adjust
the
descriptors
is
fine,
okay,
but
I
I
would
think
that
that's
a
valid
use
case
where
someone
has
an
s
bomb
and
wants
to
find
the
the
container
images
that
that
s1
prefers
to.
C
Yeah,
I
agree
at
the
risk
of
I
mean:
we've
gone
through
three
of
these
and
it's
already
20
minutes
in
so
at
the
risk
of
completely
derailing
us.
Do
we
want
to
talk
about
you
you're,
saying
one
s
bomb
referring
to
multiple
images?
C
C
C
C
To
your
head
by
all
means,
share
it,
and-
and
I
think
that
sounds
fine
michael
also
raced
to
sand.
I
don't
know
if
michael
also
has
an
answer
to
that.
Michael.
D
So
that
is
one
way
of
doing
it.
There
are
multiple
other
ways
of
doing
it.
I
think
right
now
we
are
not
talking
about
how
we're
doing
it,
but
what
exactly
we
want
to
do
so
it
sounds
to
me
that
this
is
yeah.
I'm
I'm
not
really
sure
I
mean
it
sounds
like
that's
just
the
user
story.
I
have
like
one
s-bomb,
let
the
s-bomb
describe
like
a
kubernetes
application,
for
example,.
D
Maybe
this
s
perm
wants
to
describe
the
micro
services
that
are
included
in
the
kubernetes
application,
so
it
would
refer
to
you
know
three
other
container
images,
someone
a
user
may
want
to
use
him.
A
user
may
want
that
information.
D
F
I'm
having
a
hard
time
thinking
of
a
scenario
where
I
would
have
one
s
bomb
that
is
pointing
to
two
different
images.
I
might
have
two
different
tags
of
one
image,
but
I'm
having
a
hard
time.
Thinking
of
that
kind
of
scenario
it's
possible,
and
so,
if
we're
thinking
that's
a
possibility,
we
want
to
cover
let's
go
as
a
user
story
and
have
it
there,
and
I
would
say
if
we
need
to
solve
it,
how
we
solve
it,
that's
more
of
an
implementation
and
let's
push
that
decision
off
until
later.
F
B
B
Everything
in
that
entire
build
chain
had
the
exact
same
provenance
of
like
the
sources
that
they
came
from,
but
then
it's
like
and
then
you
put
open
serve.
You
know
open
ssh
server
in
one
one
box,
an
open,
ssh
client
in
another
box,
and
you
know
the
sources
that
they
were
derived
from
the
build
environment
that
those
two
binaries
were
inextricably
linked
to
were
exactly
the
same
up
into
the
point
that
you
put
them
in
two
different
boxes.
B
Where
you
might
you
know
attach
attack.
You
know
you
like
yes,
they're,
arguably
different,
but
the
provenance
of
those
two
things
was
inextricably
the
same
thing.
So
if
there
were
a
way
that
you
could
have
it
in
like
a
cas
model
or
like
a
referral
model,
they
could
you
could
just
say
this:
digest
of
all
the
information
and
or
source
code
about
that
build
environment
is
literally
the
same
for
these
two.
B
C
Yeah
nisha
go
ahead,
but
I
think
we
should
move
on
after
after
this
and,
like
brandon
said
like
yeah.
D
Go
ahead.
What,
if
those
things
that
vincent
had
spoken
about
that
scenario,
what
if
it
was
described
in
the
s
bomb
itself,
does
then
do
we
need
references
for
this
scenario
at
all?
D
So
suppose
your
sperm
has,
you
know,
so
I
I'm
an
sbdx
person.
So
let
me
speak
in
that
way
in
in
using
that
as
an
example.
So
spdx
can
say
you
know
a
package
describes.
I
know.
Jaeger
tracing
and
jaeger
tracing
contains
jaeger
storage,
jaeger
controller,
I'm
I'm
just
spewing
names
out
here,
but
the
tracing
is
like
three
or
five
container
images.
D
C
Maybe
not
if
they,
if
they
do,
support
that,
but
I
think
we're,
I
think
in
general,
we're
talking
about
cases
where
the
s
bomb
doesn't
know
that
it's
referring
to
a
container
image
at
all
right.
The
s
bomb
is
is
referring
to
some
jar
produced
by
maven,
and
then
we
put
that
jar
in
an
image
and
we
put
the
s-bomb
for
that
jar
somewhere
else,
pointing
to
that
or
something
but
yeah.
C
I
think
I
I'm
happy
to
put
a
pin
in
this
and
talk
and
talk
about
other
things
and
come
back,
because
I
think
this
might
turn
into
a
larger
topic
even
than
we've
had
so
far,
but
we've
so
we've
in
general
agreed
that
the
name
and
tag
nomenclature
is
probably
referring
to
a
multi-stage
lookup
of
these
things.
That's
good.
C
These
do
sort
of
feel
like
related,
maybe
not
exactly
dupes
but
related,
where
I
want
to
query
the
registry
for
signatures.
I
want
to
query
the
registry
for
all
objects,
and
I
want
to
query
this
registry
for
objects
filtering
by
type
or
by
annotation
or
whatever.
I
think
these
are
at
least
a
cluster
of
things
along,
like
I
want
to
query,
I
want
to
query
filtering
by
type.
C
F
They're
all
similar,
the
reason
I
was
breaking
out
in
mine
is
thinking
when
we
start
to
evaluate
solutions
later
on.
We
might
have
some
solutions
that
don't
match
all
of
them
and
so
being
able
to
differentiate
here
the
three
out
of
the
five
that
we'll
get
with
the
solution.
It's
kind
of
my
thinking.
C
It
was,
I
think,
in
so
many
comments
in
one
of
these
common
threads.
There
was
a
discussion
about
how
many
of
these
do.
We
expect
to
have.
How
many
should
we
design
for
having
if
the
query
and
filter
by
type
is
done,
client-side
or
done
by
a
tooling,
that
is
that
hides
this
behavior
from
the
user?
C
I
think
we
can
also
say
that
that
satisfies
the
requirement.
It's
just
pushed
off
onto
tooling
authors,
but
they're
used
to
it.
They
they're
buttons
for
punishment,
but
yeah.
I
think
I
think
we
I
I
take
your
point,
though,
that
listing
them
separately
means
that
certain
things
will
get
more
points.
C
If
we
were
to
use
points
to
assign
value,
certain
things
would
get
multiple
points
and
some
might
not
if
they
do
need
to
be
done
on
the
client
side
or
whatever,
but
the
chat
is
once
again
blowing
up.
C
Yeah
filtering
might
be
done,
client-side
might
be
on
server
side.
Who
knows
this?
One
was
interesting
to
me.
Actually,
I
think
a
few
times
we
talked
about
most
recent
and
I
was
curious
lockheed's
not
here,
to
answer
the
question,
but
I
think
it
came
up
in
other
contexts
about
when
we
say
most
recent.
Do
we
think
that
means
when
something
is
not
the
most
recent?
I
delete
it
like
a
vulnerability
scan
result,
for
instance,
for
a
specific
instance
of
something
that
expires
and
is
not
useful
when
it
is
old.
C
In
that
case,
the
vulnerability
scan
attachment
workflow
should
delete
the
previous
one
when
it
adds
the
new
one,
and
now
you
only
have
the
most
recent
one
possibly
same
for
s-bombs,
probably
not
true
for
signatures.
I
don't
think
I
would
in
general,
expect
a
signature
to
get
deleted
when
anyone
comes
in
well,
maybe
I
don't
know
what
do
people
think
you
should
and
you
should
won
the
race.
D
Also
because
I
put
a
user
story
in
there,
that
is
kind
is
related.
Actually
I
said
most
up-to-date
or
latest,
and
you
asked
you
know:
what's
the,
how
is
that
different
from
pulling
from
latest.
C
D
And
the
and-
and
I
think
in
general,
there
isn't
a
very
good
update
story
with
the
container
with
registries
in
general.
Like
registries,
don't
real,
don't
necessarily
support,
updates
beyond.
Oh
here's,
a
rolling
tag
you
may
or
may
not
be
getting.
You
know
updates
through
here,
but
you
know
yolo
and
in
so
I
I
want
to
ask,
but
you
raise
a
good
question
there
is
reference?
Do
references
help
us
with
updates?
F
Yeah,
I'm
thinking
that
this
is
going
to
be
one
of
those
scenarios
where,
if
we
don't
solve
it
on
the
server
side,
it
can
get
very
ugly
for
the
users
that
are
going
to
be
pulling
a
signature
for
every
you
know.
Maybe
20
expired
signatures
and
one
non-expired
signature
or
scan
results
make
your
choice
of
what
people
will
be
replacing
on
an
ongoing
basis
over
and
over
again
and
so
having
something
on
the
server
side
that
can
allow
them
to
query.
This
can
cut
that
out.
I
hesitate,
though,
to
say
put
it
on
the
person.
F
C
Yeah,
I'm
not
I'm
not
sure
how
we
solve
that
in
a
general
case
without
having
like
enforcing
type
specific
behavior
or
something
that
I
don't
want
us
to
do.
C
The
the
nice
thing
about
updating
a
tag
for
something
right
to
go
back
to
the
point
that
a
tag
already
is
sort
of
like
a
reference.
A
very
weak
unpowerful
reference
is
that
when
you
point
latest
to
something
it
implicitly
stops
being
stopped
pointing
to
the
previous
thing,
there
is
no
like
delete
latest,
create
latest
you
could
do
it,
but
don't
for
the
race
condition
problem.
C
I
wouldn't
want
us
to
say
like
have
the
specs
say
that
vulnerable
the
vulnerability
report
type
of
thing
can
only
point
to
one
thing,
and
so
you
must
delete
it,
or
you
must
update
that.
You,
like
have
an
update,
end
point
to
say
that
it
was
this
and
now
this
or
something
I
don't
know
if
we
can
solve
it
in
general,
I
think
the
race
condition
issue
is
real,
but
solvable
already
by
etags
or
other
existing
http
semantics
that
we
should
take
advantage
of
in
the
registry
in
general
nisha.
D
I
I
guess
I
still
don't
have
an
answer
to
whether
that
is
in
scope
or
not
like
is,
is
managing
updates
in
scope
for
this
discussion
or
not
because
we've
like
focused
on
reference
types
specifically
to
refer
to
other
objects.
F
I'm
gonna
say
I'm
lumping
this
into
one
of
three
scenarios.
Whatever
solution,
we
come
up
with,
it's
either
going
to
be
pushed
off
to
the
artifact
creator,
to
clean
up
their
stuff
to
the
registry,
somehow
to
magically
do
that
deduplication
and
filtering
out
or
to
the
client
to
just
download
everything
and
filter
it
out
after
the
fact-
and
I
think
it's
up
to
us
to
say
you
haven't
all
given
whatever
we're.
Creating
here-
is
the
best
option
with
what
you're
going
to
get
out
of
whatever
we
make
of
those
three
yeah.
H
Just
in
the
interest
of
time,
I
think
we
all
agree
that
as
a
use
case,
this
needs
points
to
kind
of
like
go
back
to
the
previous
analogy,
whether
we
solve
it
or
not,
is
or
how
we
solve
it.
We
can
probably
discuss
going
forward
right.
H
We
know
that
there
is
a
problem
with
ordering,
because
somebody
can
keep
pushing
vulnerability
scans
on
a
daily
basis
or
even
like
on
an
early
basis,
and
the
thing
can
just
explode
and
you
want
the
latest
without
having
how
is
a
separate
question,
but
I
think
it's
important
as
a
use
case
to
at
least
discuss.
It
might
be
the
thing
and
maybe
we
won't
solve
it,
and
that's
okay,.
C
Okay,
thank
you
all
right.
As
a
user,
I
want
all
stored
objects
to
reference,
a
container
image
to
be
deleted
when
a
container
image
is
deleted.
Here's
a
fun
one
because
I
think
the
next
one
is
actually
the
opposite
right.
I
don't
know
and
and
that
all
of
that
together
says
to
me
that
we
shouldn't
specify
it
and
should
let
clients
and
their
registries
sort
sorted
out
whether
deleting
an
image
deletes
all
the
things
referring
to
that
image.
If
possible
or
not,
I
think,
there's
an
argument
for
either
case.
Does.
G
F
We
enter
the
arena,
do
we
have
to
do
we
have
to,
and
by
that
I
mean,
is
this
something
that
can
be
decided
based
on
how
you
push
your
artifact
up
to
the
registry?
If
you
push
your
artifact
with
a
tag,
it's
not
going
to
get
deleted.
If
you
push
it
without
attacking
just
a
reference,
then
it
would
get
deleted.
C
I
completely
agree
with
the
sentiment
that
we
don't
have
to
decide.
I
think
that
the
tag
semantics
is
actually
something
we
do
get
to
decide
right.
What
happens
if
you
tag
a
signature
on
an
image
it's
up
to
the
registry
if
they
want
to
untag
it
and
delete
it
when
the
thing
it
points
to
goes,
I
I
like
I
mean
correct
me
if
I'm
wrong,
that's
sort
of
a
strong
behavior.
So
that's
true,
but
I
don't
think
it's
against
the
spec.
I
don't.
F
Think
that's
taking
you're
thinking
of
the
reference
tag
scenario
right.
So
if
we
go
with
that
solution
yeah,
I
agree
with
you.
If
there
are
other
solutions
out
there
that
might
have
some
kind
of
reference
pointer
in
the
descriptor,
we
might
have
more
granularity
there
to
be
able
to
pick
and
choose
between
these
two,
as
as
the
artifact
creator
yeah,
I
think.
C
In
general,
however,
we
solve
this.
I
think
there
will
be
users
who
want
both
and
I
don't
think
we
can
specify
behavior
for
them,
because
we
we
don't
want
to
pick
a
user.
So
so,
even
if
it's
a
tag,
even
if
it's
literally
the
like
tag
scheme
that
like
cosign
uses
today,
we
are
in
charge
of
this
spec.
We
could
say
that
things
like
this,
even
though
they're
tagged
to
get
deleted.
I
don't
actually
want
that,
but
we,
you
know
it's
possible
to
do
it
yeah,
but
I
don't
think
we
should,
because.
F
I'm
thinking
of
some
of
the
other
scenarios,
where
the
artifact
is
not
necessarily
tagged,
and
so
if
the
artifact
is
not
tagged
then
then
we
have
the
choice
as
the
artifact
creator,
of
which
of
these
two
we
want,
and
so
we,
as
the
spec
designers,
don't
have
to
pick
and
choose
between
these
two
options.
That
becomes
a
user
decision
later
on
yeah
and.
C
And
even
even
embedded
in
that
statement
is
an
assumption
that
tags
pointing
to
things
has
something
to
do
with
garbage
collection,
which
is
outside
of
oci
specs
in
general.
So
all
the
more
reason.
I
think
this
is
like
a
third
rail
of
decision.
I
don't
want
to
decide
to
make
sanjay
go
ahead.
H
I
want
to
get
the
user
expectation
defined
from
this.
That's
what
I
think
this
is
more
important,
but
if
I
delete
the
container
image,
will
I
be
able
to
go
back
and
get
the
references
that
api
needs
to
somehow
come
out
as
an
implementation
detail,
but
from
a
user
story
side?
If
I
delete
the
container
image,
will
my
clients
continue
be
able
to
fetch
this
or
not?
H
That
distinction
needs
to
be
made
and
whether
we
make
it
as
okay
delete
references
or
keep
the
container
image
or
somehow
manage
to
keep
the
references,
but
the
container
image
would
be
a
separate
thing.
I
can
give
you
a
specific
example
here,
which
is:
we've
had
challenges
where
customers
clearly
say.
Why
is
my
space
not
going
like?
How
is
that
use
case
addressed
here
is
what
I
would
like
to
kind
of
like
that's
what
I
I'm
hoping.
We
can
get
some
answers
on
yeah.
I
think
that's
fine.
C
To
jump
to
jump
ahead
to
how
I
imagine
we
could
write
this
in
a
spec,
we
could
say
you
know,
for
example,
when
a
container
image
when,
when
the
thing
being
referred
to
is
deleted,
the
registry
may
delete
all
the
things
that
only
existed
to
point
to
that
thing:
the
registry:
it's
up
to
the
registry
to
decide,
and
it's
up
to
you
as
the
user
to
decide
which
registry
behavior
you
want.
You
might
be
able
to
configure
that
on
your
registry.
You
might
leave
the
registry
that
has
the
behavior.
C
You
don't
want
and
go
to
a
different
registry
that
has
the
behavior
you
do
want.
I
think
that's
the
best
we
can
do
as
an
example
of
like
the
registry
is
allowed
to
do
this
you
as
a
user
beware!
The
registry
is
allowed
to
delete
the
signatures,
pointing
at
the
things
that
you
deleted,
but
they
might
not.
Does
that
sound?
Okay.
H
I
think
that's
fair.
Do
we
see
this
becoming
like
okay?
Let's
I'm
not,
I
don't
want
to
get
into
the
implementation.
I
just
want
to
be
careful.
H
So
I
I
was
kind
of
like
trying
to
understand
like
if
we
we
had
the
we
had
a
similar
concept
of
like
is
catalog
supported
right,
like
the
catalog
api
might
not
be
supported
in
many
registries,
but
the
spec
exists
or-
and
we
reserved
it
as
this
is
something
that
we
want
to
do.
Our
tag
listing
is
expected
in
a
particular
way.
So
do
we
get
down
to
the
fact
of
there
might
be
an
option
that
we
can
on
a
per
request
basis.
Tell
what
to
do.
H
Would
that
lead
into
something
like
that,
or
is
this
use
case
about
just
saying
that
registries
may
implement
this
behavior
is
in
either
way
kind
of
like
works
right?
I.
C
Think
I
would
like
to
reduce
our
scope,
I
think
from
the
beginning,
from
the
first
meeting
of
this
I
my
goal
was
to
reduce
the
scope
of
this
to
something
we
could
deliver
and
iterate
on.
I
think
one
possibility
is
we
just
say:
the
registry
may
do
whatever
the
hell
it
wants.
When
you
delete
a
container
image
it's
up
to
the
registry.
C
I
think
we
can
add
descriptive
prescriptive
behavior
later,
even
before
cutting
a
release
of
this
spec
like
I
think
we
can
iterate
on
it
and
say
like
if
there
is
a
delete
with
recursive
equals
true
or
delete
and
references
blah,
blah
blah,
that's
something
we
can
design
later
if
we,
if
we
think
we
want
to,
but
I
think
I
would
rather
rather
make
as
little
change
as
possible
because
yeah
brandon
go
ahead.
I.
F
I
want
to
expand
the
scope
for
the
second
one,
though,
because
I
think
you're
reading
it
one
way,
and
I
I
read
it
a
much
more
dramatic
scope,
which
is
that
you
may
want
to
set
up
a
registry
server
that
is
separate
from
your
other
container
image
registry
server.
That
is
just
the
security
signature
registry
server
and
then,
when
you
run
your
scans
or
when
you
run
your
image
controller,
you
say:
pull
the
image
from
over
here
and
validate
the
signature
from
over.
There
sure.
C
I
think
that
is
an
entirely
valid
reading
of
that
sentence,
and
so
I
will
put
my
possible
spec
language
associated
with
the
previous
thing,
because
I
think
you're
right
it
might,
I
might
be
misreading
there
is
still
the
issue.
I
think
I
think
we
all
have
the
question.
C
Some
of
these
other
ones
also
pointed
to
the
question
of:
should
it
be
allowed
for
a
thing
to
exist
in
the
registry,
pointing
to
a
thing
that
doesn't
exist
in
the
registry.
Can
I
put
a?
Can
I
push
a
signature
to
the
registry,
but
not
the
image
it's
signing,
and
I
personally
think
that
should
be
allowed
to
support
this
case
of
having
your
signatures
in
one
registry
and
your.
You
know.
G
C
Unless
we
come
up
with
some
way
of
pushing
the
the
thing
and
its
signatures
or
something,
but
in
the
favor
of
reducing
scope,
I
would
rather
not
design
that
right.
F
I'm
also
going
to
add
that
we
just
approved
the
ability
to
have
a
sparse
image
index,
a
sparse
index
on
oci
and
so
an
index
of
points
of
things
that
don't
actually
exist
on
your
registry
and
so
that
just
expands
over
to
this
side.
So
I
think
we've
already
solved
that
elsewhere.
Okay,
great.
E
I'm
wondering
if
there
are
like
if
this
then
this
or
a
sentence,
pattern
that
we
can
describe
almost
all
of
these
things
to
put
it
into
a
bullet
list
in
the
in
the
repo
and
then
we
can
move
on
from
this
and
start
to
design
the
apis
that
could
enable
80
or
90
of
the
asks
like.
I
don't
think
we
can
sit
here
and
talk
about.
I
want
things
that
reference
non-existent
things
like
that's
one
person's
asks
like.
E
Hopefully
we
can
design
something
that
supports
99
of
the
ass
but
they're,
just
I
don't
think
we're
too
early
in
the
stage
to
discuss
any
specific
thing,
and
so,
when
I'm
wondering-
and
I
put
this
as
like
four
chats
up,
can
we
describe
this
in
three
different?
E
Can
each
of
these
be
described
in
three
different
things?
I
want
to
upload
something
to
the
registry
xyz
that
relates
to
this,
or
is
of
this
format
or
references.
This
thing
I
want
to
query,
inspect
or
view
something
in
the
registry
that
gives
me
most
recent
things
or
and
that
those
become
bullet
lists
that
are
grouped
under
that
or
I
want
the
ability
to
automate.
So
this
is
like
I
can
determine
that
there
are
old
tags,
and
so
I
can
take
this
action.
E
C
Yeah,
I
think
two
things
one
is.
If
you
I
I
tried
to
dedupe,
I
tried
to
cluster.
I
was
a
little
conservative
in
my
clustering
because
I
didn't
want
to
over
over
cluster
into
like
three
points.
If
you
think
that's
a
useful
grouping
by
all
means,
take
this
list
copy
it
somewhere
else
copy
it
later
in
the
docs
you
know
like,
like
put
them
into.
I
think
it's
a
good,
a
good
grouping
in
general
of
like
how
do
I
put
things
into
the
registry.
C
How
do
I
get
things
out
of
the
registry
and
then
there's
probably
like
miscellaneous?
I
know
that
we
are
four
meetings
into
this
group,
but
we're
also
a
year
into
this
discussion.
So
some
of
these
have
already
come
up
in
previous
discussions
and
I
think
a
lot
of
the
people
have
been
a
part
of
those.
So
so
I'm
you
know
sensitive
to
the
fact
that
we
shouldn't
go
straight
to
solutions,
but
you
know
we
have
to
get
the
solutions
eventually.
C
Somehow,
but
but
good
I
mean
yeah,
I
think
maybe
what
I'm
gonna
take
from
that
is.
I
was
too
conservative
in
my
grouping
and
possibly
we
could
have
grouped
it
more,
but
you
know
there's
there's
an
opportunity
there.
Maybe
that's
a
good
action
item
for
next
week.
Don't
just
yourself
do
it
if
you
do
it,
that's
great.
I
think
I'm
also
going
to
do
it
and
see
how
we
how
we
come
up
with,
like
the
three
main
buckets
of
things
or
whatever
or
four
or
five.
C
Yeah,
we
are
now
at
this
one
copying
container
and
its
references
to
another
registry.
I
think
this
is
an
actual
interesting
cross
if
we
cluster
them
into
three
groups
or
whatever,
with
like
pushing
and
pulling
not
putting
pushing
and
pulling
is,
is
too
is
already
used,
but
like
putting
information
into
the
registry
and
getting
information
out
of
the
registry
when
you
copy.
C
That
is
an
overlap
of
those
two
things
you
are.
You
are
pulling
all
the
stuff
you
want
out
of
there
and
pushing
it
over
here,
and
I
don't
know
if
we
should
just
think
of
that
as
a
copy
as
like
a
pull
and
a
push
that
a
tool
can
automate,
or
you
know
if
that's
gonna
be
like
a
single
bulk
export
bulk
import
api.
C
I
don't
think
we
need
that,
but
I'm
happy
to
design
that
if
people
want
to,
I
think
an
interesting
part
of
this
is
this
quirk,
which
is
a
subset
of
the
references
to.
I
think
it
was
a
thing
I
said
to
brandon
earlier,
which,
like
the
client,
could
do
that
filtering.
C
You
know
like
we're
not
going
to
do
as
well
as
as
someone
just
unconstrained
by
the
spec
writing
process
a
thumbs
up
from
brandon
anisha.
You
have
your
hands
up
hand
up.
D
So
after
listening
to
all
of
these,
it
seems
to
me
that
we're
asking
for
a
database
like
operations
on
the
registry
is,
is
that
what
everyone
else
is
feeling
right
now,
or
is
this
just
me.
C
D
So
I
mean
there
is
the
there
are
the
card
operations
and
I
think
we
are
unsure
of
whether
we
will
include
all
of
those
operations.
But
there
are
other
things
like
joints
and
and
that's
that's
the
thing
we
want
to
enable
is
the
relationships
so
we're
trying
to
simulate
joints
really.
C
D
D
So
if,
if
I
put
on
a
database
hat
that
sounds
like
a
joint
to
me,
that
sounds
like
joints
to
me,
and
by
that
I
mean
you
know
there
is.
There
is
some
kind
of
tool
or
language
that
describes
how
how
to
like
the
the
intent
of
the
the
intent
of
the
query
like
what
exactly
I
want
to
query
for
so
there's
things
like
filtering
based
on
the
artifact
type
filtering,
based
on
the
the
relationship
I
mean
I
I
like
I'm
thinking
of
yeah.
C
The
the
filtering
conversation
definitely
makes
me
want
to
do
this
client
side,
at
least
for
now,
like
at
least
in
the
first,
the
first
minimal
minimum
viable
spec
of
this.
I
don't
want
to
care
about
filtering
at
all
by
artifact
type
by
anything
I
don't
want
to.
I
don't
want
to
specify
any
of
that,
and
clients
can
do
that
using
whatever
they
want.
They
can
join
against
another
registry.
C
They
can
filter
based
on
what
day
of
the
week
it
is,
I
don't
care,
and
then,
when
we
have
that
behavior
in
a
client
or
some
clients
and
the
client
authors
say
man.
This
was
really
difficult,
because
the
registry
was
too
stupid
to
help
me.
Then
we
can
add
those
smarts
based
on
real
world
feedback.
Does
that
brandon's
got
his
hand
up?
What's
that.
F
Minutes
to
the
end-
and
this
was
super
productive,
so
I'm
not
complaining
at
all-
I
I
would
say
that
we
might
want
to
avoid-
and
it's
kind
of
sad
and
just
comment
that
we,
I
think,
we're
getting
a
little
bit
into.
How
do
we
implement
this,
where
it
might
be
easier
just
to
take
a
step
back
and
say:
are
these
use
cases
that
end
users
might
want,
and
then
yes,
okay,
let's
go
ahead
and
pass
and
just
go
to
the
next
one
versus
otherwise.
C
Absolutely
I
think
we
will
continue
doing
this
next
time
is
roughly
my
guess.
I
think
so
far
we
haven't
identified
any
that
aren't
use
cases
right
like
none
of
these.
So
far,
did
we
say
no.
We
don't
want
that.
I
think
we
just
said
we
don't
want
it
this
way
or
this
overlaps
with
this
thing,
so
good
feedback
for
next
time.
I
think
we
will
pick
up
and
keep
going
hopefully
faster
or
do
it
over
another
two
meetings
or
something,
but
I.
C
This
was
useful
and
we
came
to
some
general
broad
agreements,
which
I
think
I
will
document
at
the
top.
So
it
doesn't
doesn't
look
like
we
didn't
come
to
anything,
but
I
think
people
agree
for
now
put
more
onus
on
the
client
than
we
probably
want
in
the
fullness
of
time.
Things
should
be
referred
to
by
digest,
but
tools
and
clients
and
users
can
look
up
from
name
and
tag
to
digest
to
things
referring
to
that
digest.
C
Another
one
was:
don't:
have
the
spec
specified
deletion,
behavior,
cascading,
delete
or
non-cascading
delete?
I
think
we
agree
on
that.
Does
anyone
else
have
any
thing
that
we've
talked
about,
that
they
are
happy?
We
agree
on.
G
C
C
Thank
you
all
right,
then.
I
think
we
all
deserve
a
nice
break
and
I'll
meet
you
all
back
here
next
week
to
go
through
more
of
these
have
a
lovely
week.
E
E
I
added
some
trying
to
do
more
distilling
so.
C
Nice,
thank
you
I
will.
I
will
also
do
that
or
amend
yours
and
maybe
yes,.
E
Let
me
know
if
you
don't
think
these
categories
are
appropriate,
but
all
right,
continuing
slack,
bye,
see
everyone.
Thank
you.