►
From YouTube: [OCI-WG] Reference Types - 2022-04-26
B
C
A
So
the
only
per
I
see
the
only
agenda
item
was
the
proposal
e
updates,
which
I
put
on
this
morning.
Brandon
I
saw
you
just
merged
it,
so
not
sure
how
you'd
like
to
proceed.
A
I
guess
there's
two,
I
guess
you
know
kind
of
think
about.
It
is
there's
two
approaches
to
think
about
it.
You
know
we've
started
discussing
what
it
looks
like
to
submit
back
to
the
oci.
I
guess
it's.
The
combination
of
the
tob
you
have
to
look.
I
think
our
working
group
reference
types
charter
said
to
go
back
to
the
tob.
I
actually
don't
remember,
have
to
go
back
and
check,
but
I
think
ultimately
we're
they're
looking
for
us
to
make
a
recommendation
for
what
we'd
like
to
propose.
A
A
There
was
some
additional
feedback
that
we
were
thinking,
but
I
was
thinking
I
was
talking
to
sanjay
and
lockheed
oh
by
the
way
lockheed
couldn't
make
it.
Today
he
had
a
conflict,
he
apologizes.
He
had.
You
know
something
come
up
that
he
just
couldn't
make
it
so
is.
Do
we
want
to
discuss
the
additional
feedback
on
e,
or
do
we
want
to
start
framing?
What
does
the
next
steps
even
look.
C
Like
I
know
I'll
take
additional
feedback,
I
saw
that
lucky
was
asking
for
an
extra
week
for
stuff
to
happen.
I
didn't
see
anything
happen
for
a
week
since
that's
why
hit
merge
on
today.
Just
I
hadn't
even
looked
at
the
notes
for
this
meeting
to
see
you
want
to
talk
about
it
still.
I
just
figured
had
a
bunch
of
approvals
on
there.
C
Yeah
and
kind
of
thinking
back
and
I'll
go
look
at
the
comment,
but
thinking
back
to
last
week,
I
am
concerned.
I
want
to
make
sure
that
we
do
address
whatever
registry
operator
concerns.
There
are
to
make
sure
that
we're
hitting
those
and
if
we
span
too
far
from
where
e
was
starting
from
you
know,
if
we
were
looking
for
a
lot
of
change
in
there,
then
maybe
it
makes
sense
to
make
a
proposal
left
and
that
way
we
can
just
sort
out
and
say:
okay,
look.
We
at
least
saw
this
thing.
E
E
Ge,
like
it's
merged,
but
that
doesn't
mean
it's
set
in
stone.
It's
set
in
you
know
code,
so
I
haven't
personally
been
able
to
take
a
look
at
it
this
week,
but
just
general
vibe,
it
seems
like
people
are
on
board
with
it.
I
again,
I
don't
know
like
specifics
of
things
that
we're
still
discussing
I'm
interested
in
talking
about
it,
whether
or
not
he
is
the
thing
we
want
to
go
with.
I
like
pin,
pin
that
for
now
like
what
is
the
practical?
E
What
what
are
we
producing
to
say
that
proposal
x,
whatever
for
some
value
of
x,
is
the
one
we
are
taking
or
what?
What
are
we
doing
right
like
what?
What
is
what
is
the
result
of
this?
I
think
we
generally
have
an
idea
of
like
we
as
the
body
of
people
working
on
this
will
come
to
the
I
guess
tob
with
like
this
is
the
thing
we
want
to
merge
into
your
various
specs
is
that
people's
do
people
agree
with
that?
As
the
thing
we
are
doing,.
B
So
just
correction:
I
thought
that
was
a
community
not
to
be
so.
We
would
present
this
in
a
community
meeting
that
has
representation
from
the
spec
maintainers.
E
Sorry
I
mean
yeah,
I
think
I
think
it's
it's
going
to
be
difficult
right,
because
we
will
need
we
are
going
to
make
changes
to
distribution
spec,
presumably
we're
going
to
make
changes
to
image
stack,
presumably,
and
so
we
or
other
new
things
who
knows
and
so
we'll
need
buy-in
from
those
specific
people.
My
impression
of
my
year,
plus
of
history
with
the
oci,
is
that
the
community
meeting
is
not
a
useful
forum.
E
I
thought
I
thought
we
would
engage
with
tob
to
say:
hey
tob,
you
are
not
distribution,
spec,
maintainers
or
image,
spec
maintainers,
but
you
some
of
you
are-
and
you
at
least
have
some
like
weight
behind
you
to
say
like
well,
not
just
this
group
of
jokers
no
offense
just
this
group
of
jokers,
but
also
tod,
thinks
this
is
a
good
direction,
and
with
that
we
can
say,
distribution
spec,
like
you
know,
please
let
us
know
if
there's
concerns
and
we'll
change
things,
but,
like
mostly
that's.
B
D
I
think
I
agree
with
with
some
of
that.
I
think
that
my
from
the
conversation
I
had-
and
I
think
we
talked
in
slack
a
little
bit
it-
it
doesn't
sound
like
the
tob
necessarily
wants
to
do
that
unless
they
need
to,
and
so
if
we
have
distribution,
spec
changes,
we
should
take
those
to
the
distribution
spec
maintainers.
If
we
have
image
spec
changes,
we
should
take
those
the
image
effect
maintainers.
D
If
we
want
a
new
spec,
we
should
ask
the
tob
and-
and
probably
you
know
I
mean
I
think
I
it
would
be
great
if
the
tob
would
say.
Yes,
this
is
the
way
we
would
do
it
and
we
were
going
to
stamp
our
approval.
I
just
I
don't.
D
I
don't
think
that
that
is
something
that
they
will
do,
but
maybe
there
are
people
who
are
on
the
tob
or
have
talked
to
people
in
the
tv
that
think
differently.
E
E
Spec
changes,
but
some
things
require
input
or
consideration
across
the
boundary,
and
so
if
we
go
to
distribution,
spec
first,
for
instance
and
say,
distribution,
spec
we'd
like
to
make
this
change
and
they
say,
go
for
it
and
then
we
go
to
image
spec
and
say
we'd
like
to
make
this
change
and
they
say:
oh
wait,
but
change
this
in
a
way
that
is
incompatible
with
distribution.
Spec
stuff,
that's
already
approved,
and
now
we
have
to
like.
E
Do
I
don't
know
getting
everyone
on
the
same
page
is
hard
in
my
experience,
and
so
that's
why
I
thought
we
would
be
not
like
people
disagree.
Just
people
aren't
in
the
room
together
to
agree
right.
That's
why
I
thought
he
would
but
you're
right.
I
think
I
think
they
have
mentioned
that
they
don't
want
to
be
like
arbiters
of
decisions.
So
much
as
like
yeah,
that's
the
that's
the
spec
maintainers
job,
but
there's
a
coordination
exactly.
E
E
Silly
idea
yeah,
who
we
need
some
relative
quorum
of
distribution,
spec
folks
and
some
relative
quorum
of
image
stuck
folks,
presumably
in
the
past,
getting
quorum
of
either
of
those
has
been
difficult.
But
maybe
if
we
just
you
know,
trick
them
and
promise
them
a
car
if
they
show
up
to
the
zoom.
A
C
Oh
jump
in
there
we
were
saying:
does
this
need
to
go
t
or
be
or
not,
and
the
one
area
I
think
we
do
need
to
hit
the
to
be
on
is
we're
talking
about
a
new
spec
for
artifacts
themselves,
just
a
new
media
type
that
wouldn't
be
an
image
spec
media
type.
B
So
the
last
meeting
community
meeting,
where
I
had
brought
up
this
quorum
of
maintainers,
the
response
I
got
was
that
there
are
maintainers
in
this
group
that
should
be
able
to
work
on
something
that
would
yeah
that
would
be
used.
B
So
something
can
yeah
something
could
be
proposed
for
either
one
of
like
the
distribution
spec
or
the
image
spec,
depending
upon
who.
What
maintainer
represents
this
working
group?
They
could
propose
something
and
then
say
to
you,
know
to
the
effect
of
of
in
order
for
this
to
work.
B
These
changes
to
image
spec
need
to
be
need
to
be
merged
in
as
well,
and
we
need
a
representative
from
image
spec
or
an
image
spec
maintainer,
to
weigh
in
on
it.
Maybe
we
can
start
from
there
or
what
I
don't
know
josh.
Are
you
a
maintainer
of
distribution,
spec.
G
I
am
john,
is,
I
forget,
who
else
is
in
the
group
that
could,
but
I
have
a
you
know,
at
least
in
distribution
spec.
I
have
the
feeling
that
they
know
that
we're
doing
this
and
so
there'd
be
a
general
kind
of
consent.
I
know
mike
brown
is
in
support
of
what
we're
working
on.
So
I
think
you
know
we've
been
doing
this
for
a
few
months
and
I
think
if
we
come
to
them
with
this
it'd
be
hard
for
them
to
turn
that
away.
I
can't
speak
for
image
spec.
G
I
guess
where
I'm
confused
is,
if
we're
already
having
this
conversation
like,
where
are
we
putting
things?
Does
that
mean
that
we're
on
the
same
page
with
what
the
thing
is
like?
No
matter
how
we
divide
it
are
we
are
we
on
the
same
page
with
proposal
e
or
do
we
need
to
go
back
to
the
drawing
board
and
revise
that
and.
G
A
That
there
was
some
additional
feedback.
I
think
the
question
is:
we
were
just
trying
to
figure
out,
as
we
were
framing
like
very
clearly.
We
were
at
least
for
me.
You
know,
for
us
from
the
you
know.
The
auras
artifact
stuff
that
we've
been
doing
is
that
we
purposely
did
not
put
a
lot
of
feedback
on
me
because
I
wanted
to
give
space
for
others
right,
because
there
was
a
lot
of
discussions
and
so
forth.
That
came
to
that.
A
So
we
we
just
wanted
to
just
make
sure
that
others
had
much
opportunity
to
provide
the
feedback.
The
there's
you
know,
questions
around
different
summer
annotations
some
are
properties
and
and
so
forth.
There's
you
know
paging
there's
a
couple
other
relevant
questions,
but
the
the
two
basic
pieces
is
changes
to
an
existing
spec
which
there's
a
bunch
of
questions
around
versioning.
Regardless
of
what
changes
we're
doing,
there's
a
versioning
question
and
then
for
a
new
spec.
You
know
what
is
the?
What
is
the
go
forward?
Path
right?
A
There's
the
bridge,
we're
even
discussing
it
and
then
there's
like
a
go
forward
manifest
if
we
will.
B
A
A
B
I
have
so
my
opinion
was
that
proposal
e
was
the
bridge
and
in,
and
it
seems
to
me
that
in
in
order
for
it
to
be
the
bridge,
the
the
bit
about
querying
the
registry
pagination,
all
certain
like
actually
a
big
chunk
of
filtering
would
have
to
be
addressed
in
a
follow-up
proposal
and
the
bridge
is
well
changes
to
the
image
spec
and
adding
the
new
artifact
spec,
with
some
changes
to
distribution.
Spec.
That
addresses
these
two,
like
that.
B
G
So
one
idea-
I
have
two
things
to
say:
one
idea
was:
can
we
for
the
first
round
just
drop
some
aspect
of
the
filtering
or
the
the
pagination
just
to
like
get
it
in
and
then?
My
second
comment
was:
I
agree,
nisha
that
that
was
the
bridge,
and
so
I
want
to
understand
what
are
the
like,
what
like,
what
are
the
things
whether
they
go
to
this
spec
or
to
this
new
repo
like
what
are
the
things
that
are
keeping
people
from
like
being
on
board
with
that.
C
So
none
of
the
api
changes
none
of
the
new
specs
anything
like
that,
because
those
are
going
to
take
time
to
sort
out
and
then
the
assumption
there
is
that,
once
we
get
the
initial
state
there,
we
get
to
a
status
quo.
Okay,
people
can
use
this
thanks.
Jason
people
can
use
this
as
it
is
today
and
know
that
we
do
have
this
forward
target.
We
can
go
through
and
work
with.
People
like
distribution
distribution,
hear
concerns
from
michael
and
other
folks
about.
What
does
this
filtering
thing's
supposed
to
look
like?
E
Yeah
just
to
give
voice
to
that
silent
thumbs
up,
I
think
that's
a
very
good
approach
both
because
we
can
make
small
steps.
We
all
agree
on
before
tackling
the
the
potentially
more
hairy,
thorny
issues
and
because,
when
you
know,
distribution
distribution
picks
up
the
changes,
the
small
changes
we
all
agree
on.
They
may
come
up
with
other
issues.
Other
problems,
other
you
know
practical
real
world
concerns
or
not
right,
they
might
say,
oh
and
in
practicality,
filtering,
isn't
as
big
a
deal
as
we
thought.
You
know.
E
C
C
If
we
go
down
paths
like
that
that
might
change
the
things
that
we're
proposing
here,
though,
the
reference
type
descriptor
you
push
up,
there
might
need
additional
fields
in
there,
and
so
we
might
have
something
needs
to
be
modified.
So
any
questions
concerns
we
have
on
those
parts
now
that
we
can
sort
out
sooner
the
better
and
then
we
can
save
the
other
parts
of
how
do
we
do
some
of
the
filtering
on
those
until
later.
B
How
about
we,
maybe
brandon,
you
could
share
the
spec
and
we
can
go
through
that
now,
like
oh,
maybe
spend
the
next
few,
the
rest
of
the
meeting.
Looking
at
things
that
we
feel
can
we
can
implement
wait.
We
can
submit
right
away
and
things
that
we
think
need
a
little
more
work
or
a
little
a
few
more
steps
to
get
there.
A
All
right,
I
think
I
want
to
raise
some
questions
there
on
this.
So
there's
an
interest,
there's
a
question
of
what
kind
of
incremental
steps
that
we
can
make
that
fit
the
bigger
picture
of
what
we're
trying
to
accomplish,
because
I'm
a
little
worried
about
you
know
kind
of
frankensteining.
This
thing
together,
the
a
spec
is
kind
of
laid
out
to
cover
larger
scenarios,
and
I
think
it's
kind
of
like
the
blueprint.
Once
you
know
the
blueprint,
then
you
can
go
build
off
certain
parts
of
the
house.
A
You
can
put
the
garage
over
there
and
you
make
sure
it's
over
far
enough
because
you're
putting
something
else
in
place:
power,
water,
whatever
the
circumstances-
are
without
a
full
blueprint
of.
What's
going
on
we're
just
incredible.
We
already
have
a
couple
implementations
out
there
and
I
think
we
know
some
of
the
gaps
that
exist,
so
I'm
not
sure
formalizing.
Those
in
some
cases
help
while
other
cases
we've
been
able
to
drill
into
why
filtering
is
important
why
some
of
these
properties
are
important.
A
B
I
can
submit
a
counter
proposal
for
that
c
if
we
are
able
to
submit
something
that
is
useful
but
painful
to
users
that
gives
us
an
opening
to
submit
more
enhancements.
B
A
I
mean
I
know
we
keep
on
using
this
comment
that
it's
going
to
take
forever
for
things
to
evolve.
I
I
think
it's
our
inability
to
make
an
agreement
on
some
of
these
things
to
evolve
like
this
is.
If
you
look
at
what
you
know
we
have,
we
have
an
implementation
that
we
have
run
forward
with
that
we
have,
you
know,
learned
a
lot
around.
A
A
If
I,
if
I
look
at
kubernetes,
for
instance,
there's
a
lot
more
kubernetes
instances
out
there
right.
Every
cloud
has
thousands
and
thousands
upon
them
that
different
customers
run
where
registries
are
a
far
smaller
subset
to
those.
So
I
I
just
I
want
to
be
careful
about,
assuming
that
we
have
to
make
minor
changes
because
it
can
take
forever.
I
think
this
is
where
the
confusion
that
we've
created
has
said
others
to
say,
I'm
just
going
to
sit
back
and
wait.
B
I
I
disagree
with
that.
I
think
some
of
the
some
of
the
work
that
we're
doing
is
influencing
the
wider
community
and
influence
takes
some
time.
I'll
give
an
example
we
created
like
see,
I'm
a
I'm.
The
maintainer
of
the
third
project
turn
has
a
has
funny
to
pin
docker
files.
It's
been
what
five-ish
years
now
since
turn
was
released,
and
it's
only
in
now
the
bill
kit
is
trying
to
implement
the
same
thing.
B
It
took
five
years
to
get
that
point
across
plus
several
supply
chain
attacks.
So
I
think
it's
a
matter
of
just
you
know.
Yes,
you.
There
are
many
projects
that
have
that
long-term
vision
and
and
can
see
you
know,
can
foresee
all
the
problems
that
happen,
but
not
everyone
can-
and
I
think
you
know
this
is
an
opportunity
to
make
them
see
that
through
example,.
E
Yeah,
I
think
I
I
agree
with
that.
Nisha.
I
think
it's
a
it's
a
like
minimum,
viable
proposal
strategy
where
get
something
that
works
like
like,
you
said,
get
something
that
works,
even
if
it
is
painful
knowing
that
it
is
painful,
improve
it
in
the
ways
that
make
it
less
painful.
I
know
that
you
have
your
implementation,
that
that
is
out
and
users
are
using
and
I'm
sure
their
feedback
is
useful
and
part
of
it,
but
I
think
there's.
E
Every
every
registry
has
its
own
use
cases
and
usage
patterns
and
storage
limitations,
and
I
don't
know
that
they
would
all
conform
to
the
same
constraints
as
the
as
the
implementation
that
you
have
is
my
worry.
So
that's
that's
why
I
want
to
do
this
slow
incremental
thing.
The
other
thing
I
want
to
say
is
it's:
it's
not
like.
We
have
to
cut
a
new
version
of
the
spec
after
each
iteration.
E
E
In
the
process
on
the
way
through
and
then
at
some
point
when
things
settle,
and
we
think
that
it's
good
enough,
we
can
kind
of
cut
a
you
know
a
release
of
it.
That
seems
like
a
lot
more
sane
strategy
to
me
than
to
you
know,
build
the
whole
cathedral
and
then
stamp
it
as
done
once
it's
complete,
because
it's
never
complete.
That's
the
other
thing
about
oci
that
I
that
I
want
to
drill
into
people's
heads.
It's
not
complete,
it
never
has
been,
and
it
never
will
be.
We
need
to.
E
B
So
I
mean
I
I
I
wonder
if
we
could
instead
come
up
with
you
know,
a
part
of
proposal
e
has
something
has
an
upgrade
path,
and
maybe
you
know
we
have
to
flesh
out
what
that
upgrade
part
looks
like
what
do
we
start
with?
What
do
we
propose
next?
What
do
we
propose
after
that,
and
I
think
stephen
suggests
experience
with
actually
going
all
the
way
and
implementing
this
thing
and
iterating
over
it
and
finding
out
like
what
would
work
and
what
would
not
work
would
be
health.
E
Yeah,
definitely
in
the
in
the
proposal
where
we
say
this
is
what
we
all
look
like
unequivocally
agree
on.
This
also,
here
are
some
next
steps
we
think
are
going
to
be.
You
know
important
and
in
the
pipeline
of
stuff
after
this
that
it's
not
part
of
the
proposal,
it's
not
part
of
the
thing
you're
you
know
ratifying
but
be
on
the
lookout
for
this
coming
next
things
like
filtering
things
like
paging
things
like
you
know,
etc.
A
If
you
look
at
the
scope
of
the
the
proposed,
basically
the
working
group
reference
types
proposal,
one
of
the
things
was
delivering
a
reference
implementation
to
it.
So
I
think
that's
one
of
the
things
that
we
should
probably
think
through,
and
this
is
you
know
just
because
we
have
our
feedback
from
the
way
we've
implemented
it.
It
doesn't
mean
that
others
might
have
the
same
right
like
the
point
is.
A
Is
that-
and
this
is
why
the
discussion
of
where
the
properties
exist
isn't
as
much
of
a
challenge
as
opposed
to
the
code
that
supports
it
right,
whether
it's
a
an
annotation
or
a
property
or
something
that's
not
really
super
important,
it's.
What
really
is
is
well
what
is
the
code
that
knows
how
to
index
it
and
return
it?
How
do
you
track
it?
For
you
know
life
cycle
management,
so
I
think
this
might
be
one
of
the
places
where
we
can
start
implementing
a
proof
of
concept
of
it.
A
We've
got
a
bunch
of
it
done
in
distribution,
which
could,
since
the
proposals
are
really
centering
around
the
point
here,
is
we
have
some
debate
around
some
where
the
properties
live.
But
that's
not
that's.
My
point
is
that's
not
really
the
hard
part.
So
if
we
took
the
we
can
take
distribution,
we
could
take
zot.
I
don't
you
know,
there's
lots
of
different
things
that
you
can
take
as
an
open
source
project
and
start
implementing
it.
I
think
we'll
start
to
flush
out
the
details
of
all
right.
This
does
really
matter
now.
A
Oh,
we
can
do
this
later.
If
we
just
add
this
property
now
I
think
that's
the
piece
that
kind
of
makes
it
more
concrete,
because
a
spec
is
a
spec,
but
a
spec
is
only
interesting
if
it
actually
has
an
implementation
that
justifies
it
actually
works.
E
Yeah
that
that's
a
good
point,
especially
if
it's
in
our
charter
that
we
would
produce
such
a
proof
of
concept,
is
there?
Is
there
anyone
on
your
side?
That
is
doing
that?
That
is,
that
is
like
tracking,
I
I
I
don't
know
the
elephant
in
the
room
seems
like
we
are.
We
are
consolidating
around
proposal
e.
I
don't
want
to
say
it
because
I'll
scare
it
away,
but
it
sounds
like
we're
getting
close
to
some
form
of
proposal
e.
E
Is
there
anybody
who
is
interested
in
prototyping,
that
for
in-distribution
or
in
zop
or
in
a
you
know
clean
room
register,
implementation
or
anything
to
be
able
to
start
fleshing
that
out
so
that
we
can
say
this?
Is
the
thing
josh
raised
his
hand?
I
don't
know
if
he
meant
to.
A
We've
they've
been,
there
is
a
lot
of
work
already
in
distribution
for
this,
so
there's
a
good
base
of
it.
We
basically
we
use
distribution
to
validate
our
initial
designs
to
make
sure
we're
comfortable
and
we
pivoted
quite
a
bit
one
of
the
reasons
it's
not
sent
as
a
pr
up
to
distribution
is,
as
we've
learned,
we
wanted
to
go
back
and
change
some
of
the
implementation
in
it
and
saji
could
remember
the
details.
A
Maybe,
but
I
think
that's
that
is
what's
really
important
is
to
until
you
start
building
something
you
don't
really
learn
enough
to
know
is
that
the
blueprint
you
want
to
you
know
create
and
make
a
thousand
copies
of.
As
far
as
e
or
a
I
mean
e,
I
see
really,
as
the
properties
are
named
a
little
bit
differently
in
from
a
the
big
difference
in
e.
Is
there
are
properties
on
an
existing
manifest,
and
I
think
that's
the
piece
that
we
want
to
flush
out
again
from
a
versioning
perspective.
A
What
does
it
mean
to
really
add?
Not
not.
Does
it
break
anything,
it's
more
a
matter
of
what
expectations
are
set
by
adding
those
properties.
So
I
think
doing
some
kind
of
incarnation
of
that
with
you
know,
and
I
don't
really
care
what's
distribution
or
something
else,
it's
just.
I
know
there's
a
lot
of
code
there
and
distribution
that
that's
already
there
and
distribution
has
been
the
base
that
most
projects
tend
to
start
with
when
they
build
a
registry.
So
so.
C
A
A
Point
is,
let
me
just
the
one
point
is
if
there
is
when
a
registry
is
ingesting
a
manifest
right
registry,
don't
really
care
what
the
blobs
are
right.
We
don't
really
crack
blobs,
but
we
do
crack
manifest
to
understand
what
does
the
thing
reference
so,
when
there's
new
properties
of
those
annotations
that
they're
expected
to
do
something
with
what
does
that
mean
to
add
something?
And
what
is
the
expectation
of
a
registry
not
just
that
the
distribution
spec
says:
hey
ignore
things,
because
I
we've
debated
that
one
before.
But
what
does?
E
At
least
my
understanding
and
again,
I
might
be
missing
something
about
proposal
e.
Having
not
read
it
very
recently.
My
understanding
is
that
proposal
e
at
least,
is
backward
compatible
for
existing
registries.
An
existing
registry
can
accept
a
manifest
that
includes
a
reference
field.
It
won't
know
what
to
do
with
it.
It
will
ignore
it.
It
will
just
it
will
not
do.
E
Ask
for
references
for
a
thing
it
will
say
404.
I
don't
know
what
that
means
go
away.
That
seems
non-breaking
to
me
in
a
way.
That
means
we
shouldn't
or
don't
need
to
and
therefore
shouldn't
bump
any
versions,
either
in
the
schema
version
or
in
the
meta
other
side
of
the
the
media
type.
C
A
I
don't
want
to
be
the
one
speaking
I
mean
michael's
here
from
you
know
from
aws,
I'm
trying
to
see
if
anybody
has
to
run
other
registries,
but
you
know
there's
if
a
customer
and
I'm
saying
customer
right
instead
of
just
a
user,
a
customer,
that's
paying
money
and
has
slas
if
they
upload
something
what
is
their
expectations
and
when
they
delete
something.
What
are
their
expectations
right?
A
A
So
there's
just
a
question
of
what
is
the
end
goal
of
a
user
experience
and
what
is
their
expectations
if
they
start
sending
something
up
that
says,
subject
or
reference
whichever
and
then
when
they
try
to
delete
something
down
so
and
I
have
to
drop
because
I
have
a
hard
stop,
so
I
didn't
need
to
queue
this
up.
It
was
supposed
to
be
35
after
so
I
was
expecting
it
to
be.
E
We
actually
also
have
to
run,
but
this
has
been
super
useful
and
thank
you,
everyone,
I
think,
we'll
we'll
probably
pick
up
next
week.
All
right
feel
free
to
keep
coming
and
we'll
catch
the
recording
whenever
it
goes
up
thanks
a
lot.
B
All
right,
okay,.
B
Before
everyone
goes,
this
is
one
of
those
things
that
brandon
I've
been
trying
to
figure
out,
which
is
this
version
bump
thing,
if
you
recall,
like
version
c,
like
proposal
c,
had
a
version
bump
of
3.0,
and
my
understanding
of
that
is
that
if
you
bump
it
to
3.0,
then
registries
can
indicate
that
you
know
what
what
you're
asking
of
me.
I
don't
know
anything
about
it
go
away,
but
you
had
mentioned
that
there
was
an
extendability
bit
that
says
you
could
use
the
same
version
if
you
follow
certain
rules.
C
Yeah
the
thing
we've
kind
of
leaned
really
heavily
against.
Is
this
one
little
bit
to
the
in
respect
that
just
says
hey
if
you're
reading
or
processing
this
stuff,
you
can't
generate
an
error
if
you
see
an
unknown
property,
and
so,
if
you
use
so,
if
you're
a
server,
that's
processing
this
and
you
see
an
unknown
reference
and
you're
not
programmed
to
interpret
the
reference
field.
C
You
can't
generate
an
error
from
that,
and
so
the
the
recommendation
is
that
you
must
it's
not
even
an
option
there.
You
must
ignore
that
property
doesn't
mean
you
change.
It
just
means
you
ignore
it.
You
don't
do
anything
special
with
it,
so
we've
been
leaning
really
heavily
on
this,
with
the
hopes
that,
as
long
as
we
follow
this,
we
don't
have
to
version
the
spec
and.
B
B
Yeah,
no,
I
was
going
to
ask
sajay
if
he
has
any
thoughts
on
that,
like
in
your
in
your
implementations.
Have
you
seen
any
anything
that
goes
against
that
for
industry.
H
Yeah,
so
couple
of
things
is
one
portion
that
we
recently
faced
was
the
vulnerability
with
missing
media
types
right
so
properties,
even
though
we
expect
registries
not
to
look
at
them,
we
do
look
at
them.
That's
the
only
way
we
can
index
annotate
and
kind
of
find
out
what
the
architecture
is
and
things
like
that,
because
people
want
to
see
that
kind
of
data
when
they
come
so
the
extensibility
is
it's
okay
to
use,
but
it'd
be
good.
H
If
we
could
limit
some
amount
of
structure
to
what
the
schema
is,
but
then
again
that's
changing
image,
spec,
not
the
distribution,
spec
itself
right
the
other.
Actually
I
had
some
some
minor
questions
during
the
last
oci
call.
We
mike
brown
actually
mentioned
the
kind
of
leverage
the
extensibility
api,
so
I'm
a
big
proponent
of
that.
So
that's
why
I
wanted
to
kind
of
see
if
we
can
kind
of
like
move
proposal,
d
or
e
or
whichever
it
is
to
kind
of
like
start
with
the
extensibility
proposal.
H
There
was
also
a
question
of
whether
we've
done
the
work
to
support
the
extensibility
api.
There
are
folks
from
my
team
who's
kind
of
like
supporting
getting
a
draft
pr
out
with
an
extension
support
right
now
or
us,
but
the
base
can
be
used
for
adding
the
reference
type
as
an
extensibility.
Also
kind
of
like
supports
the
entire
plumbing
for
configuration
into
distribution,
and
things
like
that,
so
we
can
kind
of
leverage
that,
if
folks
are
interested
to
take
a
look
at
it.
Those
are
those
are
some
key
points.
H
One
one
point
like
I
know
key
folks
who
are
interested
is
not
there
and
maybe
they'll
watch
the
call,
and
I
wanted
to
make
was:
can
we
pivot
on
all
the
all
the
options
of
backward
compatibility
as
a
if
you
do
not
have
support
for
this
new
latest
greatest
thing
that
we're
supporting?
Then
this
is
the
path
you
should
use
rather
than
pitch
the
backward
compat
client
scenario.
H
Tagging
scenario,
as
the
first
part
like
send
the
customer
down
the
down
the
approach
and
yes
so
that
they
know
exactly
where
we're
going,
rather
than
pitching.
Stick
it
into
reference
first
and
then
look
at
the
artifacts.
So
that
is
one
thing
that
I
would
like
to
kind
of
like
debate:
do
we
have
an
option
to
show
them
the
way,
but
hey
here
is
all
the
here.
H
Are
all
the
stop
cap
solutions
that
you
have,
because
that's
kind
of
how
we
do
we've
always
done
apis
like
if
you
want
new
aps
use
this,
but
if
you're
stuck
with
the
old
and
what
it
is
as
an
implementation,
then
you
can
use
the
other
one,
because
I
read
the
spec
as
go
with
emit
spec,
oh,
but
by
the
way,
there's
also
artifact
spec.
H
Instead,
I
would
like
to
read
it
as
hey:
this
is
the
artifact
spec
that
we're
proposing
from
the
reference
type,
which
is
the
better
way
to
do
it,
but
given
the
current
situation
of
things,
this
is
what
you
can
do
and
you
can
leverage
the
timings,
though
that's
the
only
kind
of
like
recommendation.
I
would
like
to
make,
because,
technically
speaking,
the
entire
backup
compatibility
is
a
recommendation,
in
my
opinion,
right,
it's
how
you
can
do
it.
H
Clients
can
build
upon
it,
but
there's
no
reason
for
clients
to
actually
leverage
that
if
they
have
this
new
api,
so
those
are
probably
the
two
points
that
I
want
to
make
I'll.
Add
it
to
the
notes.
But
I
think
that's
that's
one
thing
that
we
that
I
want
to
kind
of
bring
to
the
table.
C
C
D
C
An
optional
property,
and
so
I
looked
at
us
adding
another
optional
property
with
the
reference,
and
so
if
the
reference,
isn't
there?
That's
okay,
if
it
is
there
and
it
wasn't
expecting
it,
that's
also
okay,
and
so
I
think,
we've
I
think,
we've
hit
all
sides
of
that
one,
and
so
I'm
hoping
we're
okay,
but
I
still
hear
some
concerns
from
some
people,
and
so
I
want
to
make
you
know.
H
Maybe
I
can
give
you
a
give
you
a
selfish
reasoning.
I
don't
want
to
implement
references
over
image
spec.
The
reason
is
that
if
we
are
supporting
artifact
spec,
then
we
can
tell
customers
to
go
around
one
path
right
when
you're
writing
client
tools,
you
don't
go
down
both,
so
we
kind
of
like
totally
ignore
the
image
spec
implementation.
If
they
go
around
the
image
spec,
my
my
thinking
was
use.
Tags
use
all
the
backward
compact
tools,
don't
even
bother
with
using
the
api.
H
So
you
have
two
clean
parts
of
the
the
new
way
with
the
artifact
spec
with
the
filtering
api
or
the
or
the
old
ways
use
a
property
that
this,
which
is
leveraging
the
extensibility
feature
frame
and
spec.
Those
would
be
that's
what
I
was
hoping.
We
can
kind
of
like
talk
about.
C
H
Everywhere,
right
I
mean,
but,
as
you
can
see
like
the
same
thing
with
run
c
right
like
you
have
oci
runtime
as
a
specification
and
you
have
docker
specifications,
there's
going
to
be
some
fragmentation,
but
we're
not
stopping
them
from
actually
using
that.
But
I
don't
wanna
I
mean
my
hope
is
that
the
working
group
doesn't
recommend
that
as
the
first
option.
I.
B
I
don't
think
that's
what
we're
proposing
over
here.
In
fact,
I
think
we
are
trying
to
build
up
to
a
place
where
you
you
know
you
want
to
be
able
to
tell
customers,
there's
here's
this
newfangled
thing
and
it'll
be
so
much
better
for
you
just
go
use
this
tool
and
it'll
all
be
nice,
but
there
is.
There
is
like
a
place
in
the
middle
that
we
have
to
like
move
carefully
so
that,
rather
than
you
know,
rather
than
a
like
state
deviation,
we
want
a
gradual
deviation
like
we
want.
B
We
want
to
be
able
to
allow
people
to
like
slowly
switch
rather
than
have
the
fragmentation,
like
you
see
in
like
in
docker
and
rocket,
and
all
those
other
things
that
happened
before
so
we're
trying
to
we're
trying
to
actually,
rather
than
have
it
where
the
spell
the
specification
is
based
on
docker,
but
we
want
it.
The
other
way
around,
like
the
the
docker
needs
to
follow
the
specification
or
run
c
needs
to
follow
the
specification,
and
my
feeling
is
that
the
only
way
to
do
that
is
to
you
know,
make
the
increments.
F
I
I
am
done
just.
B
B
Yeah
with
regards
to
the
second
concern,
sajay
that
you
had,
I
I
think
proposal
e
you
know
meets
that,
because
there
are,
there
are
some.
There
are
some
things
in
proposal
e
that
says
like
for
backwards
compatibility.
B
You
have
this
tag,
naming
convention
and,
if
you're
going
to
switch
over
to
this
new
manifest,
then
you
are
able
to
do
all
of
those
those
things
with
the
this.
This
new
image
layout
or
this
new
artifact
layout.
H
I
think
actually,
sam
samuel's
statement
of
the
artifact
repo
is
not
a
specification.
H
This
would
literally
like
the
backward
compat
would
not
be
a
specification
in
that
sense
because
we're
not
changing
anything,
we're
literally
kind
of
like
leveraging
existing
apis
and
trying
to
use
it
in
a
particular
way
right.
So
that's
kind
of
what
I'm
trying
to
ask
is
like
is
that
that
might
be
the
path
and
how
much
of
that
as
a
spec
would
be
the
question
at
that
point
in
time.
H
I'm
trying
to
make
sure
that
if
we
do
call
that
out
as
a
specification,
we
should
be
able
to
validate
it
also
in
some
way,
and
how
do
we
validate
something
like
that
from
a
client?
Tooling
part?
That's
all
client
implementation,
also,
the
entire
backup
compat
story
is
a
client
implementation.
There's
no
server
change
so
from
that's.
Those
are
kind
of
things
that
I
wanted
to
kind
of
tug
upon
right.
H
If
we
are
saying
this
is
a
spec,
what
are
we
changing,
or
rather
are
we
just
leveraging
the
existing
specification
with
a
usability
pattern,
which
is
maybe
not
a
specification
per
se,
so
how
much?
Where
do
we
want
to
draw
the
line?
H
Is
the
other
question
that
I
would
have
I
I
one
more
point
I
probably
wanted
to
kind
of
like
discuss
was
lockheed
mentioned
about
a
couple
of
things
that
we
want
to
probably
take
take
forward,
which
is
the
the
the
fact
of
actually,
if
we
recommend
the
spec
repo,
what
do
we
put
there?
We
need
to
identify
that.
I
don't
think
creating
a
new
spec
or
anything
like
that
is-
is
a
challenge
here,
but
just
kind
of
like
acknowledging
that
the
change
is
the
image
spec,
it's
not
a
change
per
se.
C
So
we're
going
a
lot
of
different
places
there
on
on
the
what
is
the
new
artifact
effect?
I
think
I
think
it's
just
going
to
be
this.
It's
what
the
artifact
spec
is
here
and
we
just
need
to
go
through
and
write
that
in
spec
language
right.
This
right
here
is
what's
going
to
go
into
the
new
artifact
spec,
so
the
comment
we
should
pull
out
reference
from
image
spec
and
we
shouldn't
do
that.
I
know
probably
been
a
little
bit.
H
No,
I
don't
I
don't.
I
don't
think
I'm
not
okay,
maybe
I
came
across
wrongly.
I
don't
think
we
should
not
support
backward
compat.
I
mean
I,
I
definitely
am
not
gonna,
I'm
not
going
down
that.
What
I'm
saying
is
that
just
teasing
apart
for
the
specification?
This
is
what
we
propose
and
for
all
backward
compat
story.
H
This
is
how
the
recommendation
would
be
might
be
one
way
to
take
this
forward,
but
then
again
like
when
you
start
proposing
it
to
the
distribution
group
and
the
and
the
image
spread
group
we'll
see
what
happens,
because
I
don't
even
see
why
we
should
propose
this
to
the
image
spec
maintainers,
because
we
we
have
a
field
there
or
are
we
saying
that
this
is.
C
D
C
H
I
I
don't
want
to
support
tooling
for
two
things:
that's
what
I
would
say
yeah.
I
would
like
to
have
one
one
customer
base
and
I
don't
want
to
go
scan
back.
Millions
of
manifests
for
this
property
exists,
and
so
it
should
show
up
in
the
api
or
some
weird
situation
like
that.
That's
why
going
back
to
an
old
image,
spec
is
going
to
be
hard
like
when
you
have
like
tons
of
data,
cracking
open
the
manifest
and
looking
for
something
is
a
really
hard
thing
versus
supporting
a
new
path.
H
Okay,
but
clients
are
free
to
use
that
right.
That's
my
concern,
that's
what
I
wanted
to
probably
bring
to
the
table.
C
Yeah,
hopefully,
there
won't
be
too
many
old
ones
to
do
this,
but
that
that
is
a
good
point
there.
The
the
reason
I'm
pushing
for
this,
though,
is
that
it
gives
us
this
intermediate
state,
which
is
that
clients
can
work
in
this
place,
where
they're
going
between
registries.
That
do
and
don't
have
this
field
right,
but
they
still
want
to
be
able
to
leverage
the
new
api
when
they
can.
H
C
It's
a
good
concern
to
raise.
I
I
wish
this
would
have
been
a
good
thing
to
say
three
weeks
ago,
but
looking
at
this,
the
I
think
this
is
going
to
be
a
very
long
time
frame
here.
I
don't
think
this
is
going
to
happen
overnight,
they're
going
to
be
a
long
while
for
us
to
get
the
long
tail
registries
that
are
out
in
the
field.
C
Docker
hub
doesn't,
but
I'm
saying,
docker
hub
experience,
loads
of
artifactory
servers.
That
class
were
running
so
just
assuming
dr
hubbard
being
part
of
the
problem
here.
You've
got
end
users
out
there
in
the
field
that
have
versions
of
red
trees
that
were
installed
five
years
ago
and
haven't
been
touched
since
it's
gonna
take
a
long
while.
H
H
So
that
that's
a
closed
set
like
just,
I
want
to
keep
them
through
and
complete.
Somehow,
where
I
can
reason
with
this
part
is
done.
This
part
is
all
old,
not
maintained
two
client
code
bases
to
support
old
and
new,
but
I
I
see
that
interoperability
would
be
a
challenge
like
you
talk
to
an
old
registry
and
if
it
doesn't
have
the
api,
I
can
assume
that
everything
is
an
image
manifest.
I
don't
have
to
worry
about
handling
the
new
manifesto,
so
yeah.
B
Yeah,
just
I
I
just
want
to
ask
a
real,
quick
question
to
sajay.
You
said
that
you
don't
want
to
maintain
two
different
clients.
Why
are
you
maintaining
two
different
clients.
H
So
when
you,
when
you
tell
okay,
let's
look
at
a
real
customer
scenario,
let's
say
you
have
a
tool
or
something
that
actually
talks
to
the
registry
and
it
has
to
understand
a
certain
set
of
manifests
if
we
have
to
understand
both
the
reference
manifest
with
the
signature
or
like
any
reference
like
that,
plus
we
have
to
understand
the
new
manifest
you
have
to
double
the
cost
of
maintenance.
You
have
to
test
it.
You
have
to
validate
it,
you
have
to
patch
it.
You
have
to
keep
it.
It's
just
cost
wise.
H
H
Call
that
I
see-
and
I
don't
want
to
kind
of
like
talk
to
a
customer
saying
that
hey
the
specification
says,
go
this
way,
but
we
need
to
kind
of
like
make
sure
that
your
image
shows
up
in
both,
though
that's
the
reason
why
two
code
paths
always
kind
of
make
me
nervous,
because
I
sit
on
support.
Calls
like
this
like
hey
manifest,
is
not
showing
what's
happening
here
and
then
we
geo-replicate
it.
So
look
at
this
from
I.
Maybe
I
can
pull
in
a
specific
example.
H
If
we
replicate
this
across,
we
need
to
make
sure
that
this
reference
is
available
across
apis
in
different
regions
as
well.
So
you
have
to
have
two
implementations
on
the
client
to
be
able
to
understand
the
new
and
the
old
manifest
plus
you
need
to
have
the
server
to
understand
the
new
manifest
and
the
new
api
and
the
old
manifest
and
european.
So
it
just
if
you
kind
of
like
look
at
the
possible
combinations
to
test
and
validate
that's
going
to
be
discussed.
B
So
so
you're
using
you're
you're,
not
like
saying
oh,
we
have.
We
have
this
client
that
can
work
with
the
manifest
in
the
new
registry,
and
we
have
this
other
client
that
can
work.
With
the
I
mean
you
don't
have
a
situation
where
you
just
have
one
client
that
works
with
the
new
manifest
in
the
new
registry.
Only
and
doesn't
have
any
doesn't
have
any
kind
of
idea
of
what
the
old
stuff
looks
like.
H
B
You
were
saying
that
you
maintained
two
tools,
but
in
my
head
I
feel
like
the
use
case
is
more
like
you
know.
If
you
happen
to
be
using
existing
tools,
then
you
can
use
the
existing
tools
in
this
way,
but
we
would
recommend
using
our
brand
spanking
new
tool
that
works
with
the
brand
spanking
new
registries.
C
H
C
H
I
think
we
should
okay
here
here's
at
least
from
my
side
and
my
team.
Maybe
I
can
comment.
We
want
to
support
getting
this
into
distribution
as
much
as
possible,
so
that
at
least
core
distribution
has
some
some
portion
like
either
through
pr's
or
through
supporting
reviews
or
talking
to
maintainers,
and
that
is
one
of
the.
I
think
the
comments
that
I
wanted
to
address
in
the
in
the
or
aspect.
Also,
if
we
get
this
fast,
it
would
be
great
to
unify
on
that.
H
I
don't
think,
there's
a
there's,
a
challenge
that
the
we're
kind
of
like
mixing
up
road
map
and
timelines
right,
so
timelines
for
this
is
probably
going
to
be
slow,
but
I
want
to.
I
think
what
I
want
to
do
is
in
the
specification
like
when
enough
registries
support
the
new
media
type.
A
transition
can
happen
to
those
media
types
seems
like.
H
H
That
this
will
take
like
forever,
rather
than
that,
this
is
the
path
that
we
are
laying
forward.
If
you
cannot
use
this,
then
until
you
can
use
this
use,
this
older
thing
would
be
a
better
is
my
statement.
C
The
thing
is,
if
I'm
the
producer
of
an
artifact,
I
don't
want
to
do
this
until
95
of
my
end,
users
have
upgraded
their
registry
servers,
and
so,
if
I'm
producing
this
artifact,
I'm
going
to
keep
sticking
on
the
old
version
with
all
the
tags
and
everything,
probably
four
or
five
years
down
the
road,
and
so
this
this
really
holds
back.
The
adoption
of
this
is
my
fear:
go
ahead,
nisha
so.
B
My
my
sorry
about
interrupting
you,
but
I
just
want
to
really
quickly
say
that
this
is
the
reason
I
mean
this
is
the
argument
for
bumping.
The
version
spec
is
that
clients
are
able
to
clearly
delineate
what
is
supported
and
what
is
not
supported.
B
C
B
H
C
C
I
don't
know
any
clients
that
are
going
to
break
physical
references.
I
know
clients
don't
break
you
change
that
media
type.
H
C
B
C
H
Or
or
oci
any.
C
C
C
H
B
So,
where,
over
time,
I
think
I
think
brandon
we
found
the
area
that
we
may
have
conflict
on,
which
is
you
know,
do
we
do
we
stay
with
the
extension
and
what
would
that
break
versus
if
we
bump
the
version
and
what
would
that
break.
H
I'll
yeah,
it's
yeah,
I
think
we're
out
of
time
as
well.
I'll
add
to
the
notes.
I
just
want
to
probably
like
see
if
we
can
absorb
the
extension
part
of
the
api
and
the
remaining
we'll
just
kind
of
come
to
some
consensus
with
everybody
else.