►
From YouTube: [OCI-WG] Reference Types - 2022-05-31
C
C
C
B
Yeah,
so
I
thought
I'd
just
start
with
an
update
yeah.
We
need
to
write
this
down
in
a
proposal
form.
I
think
that
what
we're
finding
with
the
discussion
is,
it's
actually
really
useful,
there's
a
bunch
of
things
that
need
to
be
thought
out
properly.
Things
like
how
do
you
index
signatures
and
and
whatnot,
which
are
not
things
we're
tackling
this
with
it,
like
specifically
on
our
side,
so
help
in
that
area
would
be
good.
B
Justin
said:
there's
obvious
problems
with
things
like
ins,
so
we
need
to
use
a
a
digest
or
something
a
digest
of
a
of
a
public
key
or
something
like
that
to
make
sure
it's
unique
and
you
can't
switch
orders
and
things
like
that,
but
I
think
we
now
have
enough
to
propose
something.
The
only
concern
I'd
have
is
the
pushback
by
registries
to
say
they
don't
want
to
make
mutating
manifest
lists.
B
D
Yeah
does
anybody
we?
We
talked
about
the
etag
support
in
registries
a
long
time
ago,
even
even
like,
outside
of
the
context
of
attaching
and
signing,
and
whatever
does
anybody
remember
the
the
sort
of
high
level
pushback
on
supporting
that
or
is
it
just
like
any
change
is
impossible
to
motivate?
Were
there
were
there
specific
problems
or
just
inertia.
B
D
B
D
Pick
it,
I
think
we
could,
I
think,
I
think
the
etag
pr
for
distribution
spec
said,
should
support
e-tags
in
the
standard
way
or
whatever
and
not
must
or
not.
You
know,
whatever
anything
hard.
I
think
it's.
I
think
it's
a
good
practice
in
general,
whether
or
not
we
specify
it
it's
a
good
practice,
but
we
should
specify
it
too.
A
D
E
Yeah
I
so
this
is.
This
is
not
about
race
conditions.
If
somebody
wants
to
keep
talking
about
race
conditions,
the
one
thing
I
want
to
talk
about
is
the
size
of
the
attached
artifacts.
Is
there
it
like
this
proposal?
It's
calling
out
to
signatures
is
the
idea
that
these
are
just
small
things
like.
D
D
I
think,
for
things
like,
I
think
it
was
even
in
the
example
for
things
like
s,
bombs
that
might
get
very
large
or
things
like
at
the
stations
that
might
get
very
large.
You
can
put
that
in
a
blob
and
reference
it
through
a
manifest
to
a
blob
which
is
a
bit
clumsy,
but
it's
there.
D
D
B
Yeah,
I
think
that
what
we're
trying
to
do
here
is
find
a
trade-off
rights
like
manifests,
lists
or
manifests,
are
fetched.
They
should
be
relatively
small.
They
fetch
relatively
frequently
to
check
for
updates.
If
you
do
a
head
against
a
manifest,
you
get
a
digest
back,
which
tells
you
if
things
have
changed
and
if
you
fetch
the
manifest
you
don't
want
to
fetch
all
the
data
in
the
world.
B
You
kind
of
want
to
fetch
just
enough
to
then
make
a
decision
and
do
something
I
think
signing
falls
into
that
bucket,
because
assuming
you're
using
the
same
signing
sized
things,
it
should
be
okay,
we're
talking,
you
know
we're
talking,
bytes
or
kilobytes,
we're
not
talking
megabytes
things
like
attestations,
I
mean
s
bombs
and
things
like
that
can
easily
land
up
being
seven
megabytes
so
clearly
that
shouldn't
be
at
the
top
level.
I
would
agree
that,
like
having
the
oci
and
people
who
run
registries
putting
in
place,
some
limits
would
would
help.
B
But
I
think,
as
you
know,
as
on
the
tooling
side
as
well,
we
can
say
what
do
we
want
the
experience
to
be?
What
do
we
think
should
be?
You
know
what
is
a
reasonable
size
limit
for
for
various
different
things
and
then
do
your
question
jason.
Do
we
see
use
cases
where
we'll
have
like
thousands
of
signatures,
or
are
we
talking
tens
of
signatures
because
yeah
yeah.
D
D
You
know
humans
with
access
to
the
registry,
which
is
not
really
normal,
either
and
probably
bad.
I
I
guess
signatures
are
always
very,
very
small.
The
problem
is
something
that,
like
s,
bombs,
which
can
grow
over
time
or
two
or
three
s
bombs
might
be
enough
to
trip
the
limit.
I
don't
know,
but
again
those
just
the
answer
in
all
of
those
cases
is
blops.
The
answer
is
put
it
in
a
blob.
D
It
would,
but
only
only
by
the
amount
of
bytes
it
takes
to
have
a
descriptor,
so
you'd
have
to
have
many
many
many
more
objects
to
hit
the
limit.
Yeah.
It's,
let's
assume
for
the
sake
of
argument.
It's
100
bytes,
as
opposed
to
you
know,
potentially
megabytes
of
s
bomber
attestation
or
whatever.
B
No,
it
should
be
okay
and
like
the
the
trade-off
we're
trying
to
make
here
right
is,
if
you
put
things
in
blobs
in
manifests,
you
need
to
do.
You
need
to
fetch
the
manifest
list,
then
fetch
the
manifest,
then
fetch
the
blob.
So
you
do
a
bunch
of
round
trips
which
makes
it
a
bit
slower.
B
C
Yeah,
I
think
the
question
comes
down
to
what
things
are
we
attaching
to
our
image
and
if
it's
just
a
signature
and
an
s
bomb,
then
200
bytes.
Let's
say
that
number
no
big
deal
if
it's
that
they're
going
to
include
the
attestations
for
every
single
step
of
every
single
build
that
takes
place
and
then
start
including
daily
scan
results
and
stuff
like
that,
and
that's
going
to
every
single
day,
you're
going
to
add
to
it.
A
There's
also
like,
for
example
like,
if
you
do
at
the
stations
today
with
cosine,
then
the
way
they're
done
is
that
there's
a
there's
a
manifest
only
for
that
station
objects
like
there's
an
image
manifest,
and
every
layer
in
there
is
separate
at
the
station.
So,
for
example,
they
are
in
there.
It
has
bomb
and
whatever
like
they
are.
Your
other
like
provenance
at
the
station,
is
the
next
layer
there
so
like.
A
I
think
this
grouping
logically
also
makes
sense,
sometimes
so
so
like
this
is
also
an
option
right,
but
it's
mostly
for
like
the
client
side
to
define
like
if
they
want
to
put
like
all
the
objects
like
separately
into
the
root,
manifest
the
separate
descriptors
or
like
they
just
define
that
there's
one
reference
there
that
just
says
that
I'm
there
I
can
at
the
station
manifest
and
and
then
it
it
has
all
those
s
bombs
and
stuff
like
that
inside
there
and
as
a
client
like
you,
should
just
like
pull
in
all
the
like
it
either
like
understands
the
specific
types,
and
it
says
that
I'm
only
looking
for
s-bomb
and
then
it
just
looks
up
the
object
that
has
like
the
correct
type
or
if
it
just
says
that
I
want
all
the
stations,
then
it
just
like
gets
old
objects
that
are
have
a
link
to
that
probe.
F
G
Hey
I
had
a
couple
of
questions.
I
think
we
probably
getting
a
proposal
f
is
in
written
form
would
help,
for
example.
What
what
are
the
expectation
of
how
the
tags
will
look?
Second,
one
is.
We
did
say
that
the
artifact
repo
inside
open
containers
is
not
a
specification
because
it
doesn't
change
anything
inside
image
or
in
distribution.
G
If
we
are
leaning
towards
no
change
in
distribution
limit
spec,
then
what
value
is
this
specific
group?
Bringing
is
what
I
would
like
to
know?
Is
it
just
about
use
a
new
form
of
using
the
index
and
a
guidance?
If
that's
where
we
land,
we
should
probably
call
it
out,
as
there
is
no
change
to
any
of
these,
that
people
want
to
do.
D
Yeah,
I
think,
the
I
think,
the
that's
a
very
good
question
right.
We
had
been
sort
of
impaneled
to
describe
changes
to
distribution
or
image
spec,
and,
if
we're
not
going
to
do
that,
what
are
we
here
for?
D
I
think
we,
I
think
if
we
decide
to
go
the
route
of
not
changing
distribution
or
image
spec,
I
think
we
can
still
dis
like
specify
a
description
of
changes
when
you
do
an
attachment
or
when
you
do
when
you
you
know
the
format
of
the
index
that
describes
an
image
plus
its
signatures
or
the
format
of
the
nested
indexes.
If
we
go
that
route,
not
defining
new
types
or
new
api
endpoints,
but
new
ways
to
use
the
existing
ones.
D
The
point
of
that
specification
is
so
that
two
people
can
independently
write
a
client
and
a
server
that
can
talk
to
each
other.
So
there's
still
value
in
having
a
specification
for
how
a
client
should
send
its
attestations
and
how
a
server
should
respond
with
its
s-bombs
or
whatever.
G
Yeah,
that
makes
sense.
So
then,
we
should
probably
like
look
at
proposal
f
and
call
out
its
limitations.
For
example,
there's
no
limitation
on
the
number
of
blobs
you
can
put
on
a
registry
today,
no
limitation
on
the
number
of
manifests.
We
have
introduced
limitations
with
the
number
of
items
in
an
index
by
virtue
of
its
size,
the
number
of
scan
results
that
can
be
attached.
G
So
I
think
it's
a
it's
a
spec
with
a
limitation
by
default
compared
to
an
open-ended
implementation,
because
a
lot
of
the
conversations
are
moving
just
specific
to
signatures
and
we
missed
the
actual
description
of.
How
do
you
attach
spoms?
How
do
you
attach
scan
results?
How
do
you
attach
cat
pictures
whatever?
That
is,
so
I
think
just
looking
at
it
from
a
higher
order
that
this
is.
This
is
a
recommendation
given
the
current
situation,
but
is
it
somewhere
where
we
want
to
end
up
in
land
is?
G
Is
the
higher
order
question
that
I
think
I
wanted
to
ask
and
given
that
we
don't
have
it
written
up,
it's
becoming
a
lot
of
specific
details,
but
it
also
kind
of
clearly
is
leaning
towards.
We.
Don't
need
a
spec
repo,
because
last
time
I
remember
samuel
clearly
called
out
that
if
there's
no
changes
in
any
of
this,
it's
just
a
recommendation.
It's
just
as
good
as
an
annotation
change
or
a
or
a
config
media
type
change.
This,
which
is
not,
which
doesn't
require
an
actual
specification
per
se.
G
F
Yeah,
I
I
just
want
to
add
to
what
sajay
said.
There
are
a
lot
of
use
cases
that
proposal
f
like
addresses,
but
in
a
very
like
clunky
way
it
there
is
like
no
filtering,
and
that
was
something
that
we
had
listed
out
in
use
cases.
F
There
are
there's
no
way
to
even
solve
for
the
proliferation
of
tags.
If
you
wanted
to
create
some
kind
of
monotonically
increasing.
F
Way
of
tracking
changes
to
a
container
image
beyond
name
the
tag,
something
that
is
reasonable
to
whoever
is
using
it
there's.
So
I
I
guess
I'm
wondering
if
maybe
maybe
you
know
to
help
this
discussion
further.
We
just
need
to
look
at
proposal
f
and
do
the
usual
rubric
of
comparing
it
to
all
the
other
use
cases
and
listing
out
why
it
would
how
it
would
address
those
use
cases.
D
D
I
think
none
of
them
have
so
far,
and
this
one
doesn't-
and
you
know
we
can
make
a
g
and
h
and
I,
but
eventually
like
we
just
have
to
say
it-
meets
32
of
the
35
requirements
and
that's
good
enough
sanjay
to
your
question,
to
your
point
about
focusing
too
much
on
signatures
and
not
enough
on
the
general
attachment
of
a
cat
picture
to
my
image
case
that
I
think
that's
just
like
conversational
hygiene
when
we
say
signature,
what
we
actually
mean
is
anything,
and
that
means
small
things
and
big
things
and
that's
all
we
have
to
remember
is
sometimes
they
will
be
small
and
sometimes
they'll
be
big.
C
D
I
think
I
think
I
would
like
to
not
consider
signatures
special,
but
small
things
special.
If,
in
general,
signatures
are
expected
to
be
small,
and
so
they
can
be
attached
in
a
more
efficient
way.
D
We
should
come
up
with
a
placeholder
example
of
a
small
thing,
a
kitten
picture
as
opposed
to
a
whole
full-blown
cat
picture
and
use
that
as
the
example
of
a
small
thing,
that's
attached
that
can
be
inlined
for
for
better
fetching.
There
was
also
an
example
I
wanted
to
mention,
because
you
you
reminded
me,
there's
an
example
in
the
comment
thread.
I
think
justin
said
instead
of
using
integers
using
the
hash
of
the
public
key
or
something
that
is
very
signature
specific,
and
that
is
not
something
that
we
can
generalize
to.
D
B
Okay,
yes,
we
need
to
write
it.
I
I
also
need
a
lot
more
hours.
In
the
day,
I'm
gonna
get
silvan
to
help
me
draft
it
out.
The
reason
we've
been
focusing
on
those
issues
is
because
those
are
in
our
minds,
the
hard
ones
the.
How
do
I
attach
a
kitten
picture
or
whatever,
as
a
manifest
or
a
blob?
That's
at
least
for
us
has
been.
You
know,
that's
that's
the
area,
we're
not
not.
We
underst.
We
think
we
have
a
good
understanding
of
how
to
do
it.
B
So
that's
why
we've
been
focusing
on
the
on
the
corner
cases
where
we
think
things
are
harder,
as
the
I
think
the
oci
shouldn't
be
super
prescriptive
of
how
to
handle
every
single
case.
Their
job
is
to
focus
on.
This
is
the
image
spec.
This
is
the
distribution,
spec
and
then
tool.
Builders
should
then
consume
that,
as
as
it
is
and
build
things
around
that,
I
don't
think
I
think,
requiring
the
oci
to
define.
Absolutely
everything
is
the
wrong
thing
here.
I
think
we
should
get.
B
We
should
find
the
minimum
viable
amounts
for
collaboration,
and
that's
if
we
go
too
far,
then
all
we
do
is
kill
creativity
and
and
kill
the
ecosystem.
So
it's
about
finding
that
balance
in
general.
I
would
say
so
just
on
that,
when
you
talk
about
things
like
filtering
or
whatnot,
I
think
we
should
find
generic
filtering
solutions
not
specific
to
this
problem.
B
So
if,
if
your
annotations
or
something
like
that
or
something
you
want
to
filter
on,
they
should
be
like
generic
filtering
for
annotations,
rather
than
you
know,
tackling
this
specific
problem
and
that
can
come
out
of
this
working
group.
I
I
don't
think
the
working
group
is
useless
because
they
haven't
proposed
a
major
change
to
the
spec.
I
think
that's
actually
a
good
thing
if
they,
if
that,
if
that
is
a
conclusion,
I
think
it
should
be
here's
a
recommendation
for
how
things
could
be.
This
people
can
rally
around
this.
B
We
think
these
three
things
should
change
or
be
written
down
somewhere,
like
annotations,
will
be
used
for
this.
We
want
this
api
to
be
atomic
and
something
else
like
that's
completely.
Okay,
I
think
and
good
sorry,
nisha.
F
Yeah,
so
how
about
this
as
a
use
case,
so
one
of
the
things
that
I've
been
working
on
is
creating
s-bombs,
what
the
community
calls
micros
bombs
and
then
linking
them
together.
F
So
what
would
be
useful
in
that
scenario,
is
to
have
that
linkage
somewhere
in
the
in
the
in
some
manifest
somehow
so
that
is.
That
is
a
use
case
where
you
would
want
like.
That
is
a
use
case
where
you
have
a
small
object.
That's
linking
to
another
small
object,
that's
linking
to
another
small
object.
F
F
So
with
regards
to
your,
you
know,
question
about
whether
we
list
all
of
those
in
the
index
or
we
append
them.
That's
a
that's
a
use
case
for
that
would
be
more
conducive
for
appending
and
that's
also
a
use
case
where
the
small
thing
is
not
a
signature.
F
Yeah.
The
small
thing
is
not
a
signature,
it's
a
it's
an
s
bomb,
but
it
is
it.
It
does
not
behave
the
same
way
as
a
signature
does
so
do
you
have
any
thoughts
on
that.
B
I
do
I'll
go
very
quickly.
I
think
the
the
tool
we
have
for
trees
is
oci
indexes
and
nested
oci
indexes.
So
we
have
the
tools
we
need.
A
So,
just
to
like
explain
the
description
of
this
proposal
a
little
bit.
Maybe
we
should
just
go
over
it
a
bit.
The
terrain
has
something,
but
at
the
moment
what
it
is
describing
is
how
to
attach
blobs
to
a
descriptor,
and
that's
like
the
generic
way
of
how
you
can
define
that
that
this
plot
contains
any
data
you
want,
so
it
can
be
in
an
s
bomb.
A
It
may
also
be
like
a
list
of
response
if
you
have
multiple
of
them
and
then
at
the
moment,
as
in
the
current
descriptor
description,
the
signatures
are
like
an
optimization.
On
top
of
that
model
like
we
would
have
as
well
just
added
signatures
as
a
additional
blobs
there,
but
that
we
made
like
an
additional
optimization
so
because,
like
verifying
a
signature
is
kind
of
like
a
common
process
and
object
is
small
as
well
like.
A
We
could
do
it
so
much
faster
if
we
would
do
something
differently
for
signatures
and
we
will,
we
will
put
it
inside
annotation
like
if
you
look
at
the
annotation
keys
in
here,
like
in
in
this
case
they're
like
the
sixth
or
code
sign
like
it's.
It's
very
specific
to
signature
right
like
it's
not
really
like
proposing
any
model
of
how
you
can
like
inline
your
custom
objects
or
custom
data
in
site,
annotations.
F
That
that
doesn't
allow
you
to
you
know
account
for
new
things
that
are
coming
up
in
the
signing
community.
For
example,
tough,
is
working
on
on
a
specification
called
dsse.
F
I
mean
so
it's
easy
to
point
to
a
blob.
It's
not
really
that
easy
to
point
to
a
data
structure
that
is
moving
like
that.
That's
changing
all
the
time,
because,
especially
in
the
s
bomb
world
and
in
the
sig
well
and
in
the
signature
world,
you
want
to
be
able
to
leave
old
objects
alone
and
update
new
objects
that
reference
the
old
objects.
So
if
you,
if
you
bundle
it
all
together
into
one
object,
that
object
has
to
be.
F
You
know,
even
even
if
a
component
in
that
object
changes
the
whole
object
changes,
that's
what
that's
what
a
dag
is,
but
I
I
guess
what
we're
looking
for
is
I
don't
know
what
I
am
looking
for.
Maybe
that's.
Maybe
this
is
like
completely
not
possible.
With
registries
is
there's
some
way
of
creating
graphs,
so
I'm
sorry
brandon.
I
interrupted
you.
C
The
a
lot
of
what
you're
talking
about
reminds
me
a
lot
of
git
bomb
support,
because
that
condenses
it
down
to
a
single
digest
and
that
that
digest
can
then
be
extracted
out
to
a
whole
tree
of
data
out
there,
and
that
also
falls
in
a
nice
scenario
similar
to
signatures,
where
it's
a
very
small
piece
of
data
that
you
would
attach,
and
so
it
would
be
likely
to
fall
into
that
annotation
category.
So
that
might
be
another
place
to
look
at.
C
I
did
have
a
little
bit
of
a
concern
going
back
to
a
comment
from
chris
earlier,
where
they're
saying
you
know,
we
shouldn't
be
prescriptive
about
how
to
do
something.
We
should
just
say
here
the
hear,
the
tools
and
it's
up
to
each
individual
user-
those
tools
how
they
want
to
use
them.
C
So
I'm
just
thinking
of
a
couple
examples
like
when
bill
gets
started,
pushing
out
the
caches
and
was
using
an
index
in
that
case
for
representing
blobs
when
everybody
else
assumed
they
were
manifest.
That
was
one
issue
for
us
to
face
dealing
with
that.
One.
C
I've
also
seen
a
lot
of
cases
where
people
start
doing
the
oci
layouts,
but
different
groups
decide
on
what
annotations
they
want
to
put
within
there
and
not
everybody
puts
an
annotation,
and
so
it's
you
can't
all
parse
the
same
oci
layout
from
tools
all
over
the
place
because
everybody's
putting
their
own
annotations
in.
So
there
are
a
bunch
of
concerns
like
that
that
I
see
chris,
do
you
have
a
quick
follow-up
on
that
or
otherwise
we
should
go
josh.
B
Yeah
I'll
go
clean.
What
I,
what
I
meant
to
say
was:
we
should
have
a
minimum
minimum
required
to
make
sure
things
work
together,
because
the
the
like,
if
you
get
too
prescriptive,
then
it
just
lands
up.
Nothing
ever
happens
because
you
don't
want
to
get
everything
perfect,
but
if
we
could
just
list
like,
for
example,
the
annotations
in
common
and
agree
that
this
is
the
basic
data
structure,
we're
done.
I
think
that's
what
I
meant.
C
E
So
how
do
I?
How
do
I
vocalize
this?
So
I
think
one
of
the
things
that's
great
about
this
group
is
we're
trying
to
get
all
the
different
registries
together
and
like
come
to
terms
on
something.
Even
if
it's
not
our
favorite
thing
and
one
of
the
things
I
don't
like
about
this
new
proposal.
Is
that
jason
made
a
comment.
That's
like
I
don't
love
this
and
I
don't
think
any
of
us
do,
and
chris
said
yes,
I
don't
either.
E
I
don't
love
this
either,
and
I
know
from
last
week
or
the
week
before
there
was
mention
of-
I
think
it
was
justin-
has
some
pie
in
the
sky
registry
idea
and
the
reason
that
we
don't
want
to
do
what
the
working
group
was
doing
with
proposal
e
is
because
it
makes
all
these
changes
that
are
sort
of
in
a
intermediary,
whereas
the
this
new
thing
could
solve
all
those
problems
with
like
a
graph
model
is.
E
Is
there
a
possibility
that,
like
that,
could
be
another
proposal
or
is
that
written
anywhere
because,
like
everyone's
here
to
you
know
like
try
to
make
changes
to
achieve
these
things?
And
I
don't?
I
don't
really
want
a
stop
gap,
but
at
the
same
time,
if
everyone's
going
to
agree
on
it,
that's
most
important
to
me.
B
I
think
justin
wrote
a
gist
or
something
at
some
point,
but
it's
such
a
big
change.
It
really
requires
it's
like
it
would
be
like
a
multi-year
thing.
So
I
don't
think
realistically
it's
what
it's
in
the
timeline
that
we'd
want
here,
the
the
there's
multiple
you
know
the
registry
specs
were
put
together.
Kind
of
ad
hoc
and
and
built
along
and
stevo
did
really
great
work
with
what
he
did.
But
we've
learned
a
lot
since
then,
and
things
like
backward
compatibility
is
really
difficult
in
the
spec.
B
That's
one
of
the
things.
That's
really
hard
that
we're
trying
to
navigate
the
the
data
structures.
We
have
are
not
exactly
perfect
for
all
the
different
use
cases
we
want.
You
actually
probably
want
more
of
like
a
graph
data
structure,
something
like
what
git
has
that
would
be
way
better,
but
once
you
start
going
down
that
path,
you
see
quite
quickly
that
we
get
into
a
space
of
like
we're.
B
Gonna
have
to
rethink
big
like
everything,
from
data
structures
to
all
the
apis
and
that's
something
I
think
the
oci
should
consider
but
like
it
requires
buy-in
over
multiple
years
from
all
the
big
from
all
the
big
providers.
Oh,
it
looks
like
nisha
meth.
Oh
here
we
go,
it
might
be
that
one.
I
don't
remember
I
I
wasn't
in
the
ocean
meetings
where
it
was
proposed.
I
just
I
think,
that's
a
good
question.
So
it's
it
was
it's
like.
I
don't
think
it's
on
the
same
level.
B
E
Well,
I
guess
what
I'm
saying
is:
even
anything
here
could
take
time
to
roll
out,
and
so
everyone's
here
at
the
table
right
now
and
that's
why
I
don't
I
mean:
does
anyone
else
feel
like
a
proposal
of
that
size
would
be
completely
un
like
that
we
shouldn't
even
go
down
that
road.
D
I
I
think
it's
a
proposal
we
should
consider,
and
if
there
is
interest
and
sort
of
the
intestinal
fortitude
to
actually
do
it,
then
I
think
it's
worth
doing.
I
think
I
think
we
have
to
balance
sort
of
pragmatically
getting
something
out
and
idealistically
getting
the
perfect
thing
out.
That's
I
think
the
same
sort
of
feedback
was
on
was
on
nisha's
proposal
on
d.
I
think
it
was
that
it
was
like
this
would
be
great.
This
is
a
great.
This
is
a
graph
based
model.
D
This
is
like
everything
we
want,
but
it's
going
to
take
years
to
get
this
approved,
let
alone
rolled
out
and
available
in
enough
places
that
people
can
use
it.
I
think
we
need
to
think
both
short
term.
What
can
we
do
today
with
existing
existing
tools
or
at
least
light
modifications
to
existing
tools
and
super
long
term
about
what
we
want
the
world
to
look
like
in
2030?
2030
is
not
even
that
long
from
now
2050,
so
yeah
I
want
to
do
both.
D
I
mean
I,
I
think
we
we
need
to
do
what
we
can
with
the
tools
we
have
and
also
think
about.
Don't
don't
say:
xml,
not
xml
jml,
something
new
but
yeah.
I
I
if
folks
here,
are
interested
in
the
really
nailing
down
the
pie
in
the
sky.
Future.
Ideal
perfect
thing
I'm
here
for
it,
but
I
don't
want
it
to
distract
from
being
able
to
do
something
in
the
the
near-ish
term,
either.
E
I
guess
like
the
reason
I
say
it
is.
It
sounds
like
any
anything.
That's
not
that
anything
that
chris
please
correct
me
if
I'm
wrong
any
change
to
a
spec
in
docker's
view
is
not
in
the
in
the
v2
version
of
the
spec
is
not
a
good
thing.
B
I
would
worry
that
it
would
take
a
very
long
time
to
run
out
I'd
rather
get
something
that
goes
out
quicker
and
doesn't
require
a
ton
of
consensus,
because
if
you
have
to
get
me
to
update
my
personal
registry
at
home
and
then
jfront
to
update
artifactory
and
docker,
to
update
hub
and
google's
update,
gcr
and
github,
to
update
github
container
registry
and
and
amazon
and
microsoft,
and
the
list
gets
really
really
big
and
complicated
really
quickly,
which
means
that
the
benefit
to
users
is
kind
of
pushed
back
until
all
of
those
happen,
and
especially,
if
you
start
proposing
fallbacks,
like
I
don't
know,
I
assume
most
people
here
are
part
of
product
teams,
but
have
you
have
you
tried
to
convince
a
pm
that
it's
a
good
idea
to
implement
this
thing
when
it
already
works
like
they'll?
B
Only
do
it
when
there's
pain
later,
which
means
you
can
land
up
in
this
ecosystem,
where,
like
half
of
the
registry
is
implemented,
because
some
pm
got
convinced
that
it
was
a
good
idea
to
do
the
other
half
won't,
because
it's
just
not
a
major
use
case
for
them,
and
the
user
experience
is
really
crummy
as
a
result
that
that's
what
I'm
worried
about.
It's
like
the
the
coordination
problem
of
making
an
api
or
data
structure
change,
is
non-trivial.
F
So
here's
where
here's,
where
I'm
a
little
worried
because
there's
there's
a
number
of
stakeholders
in
this
meeting,
that
all
representatives
of
fancy
companies
that
have
money
to
be
to
give
people
to
go
and
implement,
like
whatever
a
fancy
architect
wants
them
to
do.
So.
F
If
a
fancy
architect
looks
at
this
and
says
well,
you
know
I
I
think
we
can
do
one
better
than
this
and
it's
going
to
be
awesome
and
people
are
going
to
love
it
they're
going
to
go
and
throw
money
at
it
and
you
know,
have
marketing
teams
behind
it
and
all
of
those
things.
So
my
worry
is
that
if,
if
there
isn't
any
indication
from
like
an
open
source
group
that
says
look
we're
anticipating
that
you
know
fancy.
F
Architects
are
going
to
be
wanting
all
these
things
and
we're
not
able
to
find
a
way
to
provide
that
to
them
in
the
near
term.
We're
not
talking
about
like
five
years,
we're
talking
about
like
incremental
changes
that
maybe
will
get
to
five
years,
or
at
least
some
way
of
allowing
these
fancy
engineers
to
upstream
their
changes.
F
B
If
you
got
a
quick
response
to
that,
chris
go
ahead,
I
think
it's
not
it's
not
like
either
the
oci
makes
changes
and
companies
adopt
them
or
open
source
is
dead.
I
think
it's
like
this
is
the
place
where
a
group
of
companies
kind
of
come
together,
and
they
say
these
are
our
concerns.
This
is
how
we
want
to
move
things
forward.
Where
do
we
want
compatibility?
Where
do
we
not?
And
then
we,
you
know
we
iterate
in
that
way.
The
intention
here
is
not
to.
B
I
think
the
intention
should
not
be
that
the
oci
proposes
stuff
and
then
enforces
it
on
people.
I
think
it
should
be
a
case
of
like
we
work
together
to
find
common
ground
and
places
where
we
build
on
top.
So
we,
you
know
we
can
commoditize.
The
boring
bits
have
cr,
have
compatibility
across
the
boring
bits
and
add
our
value
on
top
of
it.
It
is
a
tricky
balance
to
to
hit,
and
what
I'm
trying
to
do
here
is
not
squash
squash,
the
oci
really,
I
I'm
just
try.
B
I
think
if
we
propose
something
that
is
easy
for
more
companies
to
implement,
there's
a
higher
chance
that
more
of
them
will
do
it,
as
opposed
to
like
there's
a
there's,
definitely
a
continuum
there
and
it's
not
about
big
fancy
companies
it
turns
out.
Docker
is
not
one
of
these
by
the
way
we're
we're
the
billion
dollar
company
amongst
the
trillion
dollar
companies.
So
we
are
not
the
big
company
here,
even
in
the
trillion
dollar
companies,
though
they
have
the
same
problems
everywhere
like
there's,
always
not
enough
engineers
to
do
the
things.
B
There's
always
prioritization,
and
even
you
know
even
things
that
may
seem
like
good
ideas
to
a
small
group
like
us
have
to
be
fed
through
their
sausage
machine
of
what's
priority
and
what
isn't
and
all
of
that,
it's
it's.
So
what
I'm
trying
to
look
for
here
is
really.
How
do
we
solve
the
problem
of
all
of
our
or
all
of
us
in
a
way?
That's
lots
of
people
adopt,
so
we
we
get
this
everywhere.
So
we
get
our
users
happy!
That's
what
I'm
that's!
F
And
just.
C
F
Just
so,
you
know
jumping
up
on
that
grand
scheme
thing,
I'm
pretty
sure
that
there
are
a
number
of
people
that
also
have
other
grand
schemes
and
those
grand
schemes
do
not
have
a
common
place
to
land
in
the
in
the
in
the
specification
if
there
isn't
any
like,
if
there
isn't
any
room
for
that,
so
I
mean
like,
for
example,
the
get
model
thing
is
the
git
model
thing
is
actually
a
good
example,
because
that's
part
of
the
reason
why
I
was
talking
about
like
you
know
how
you
would
track
change
on
a
registry
beyond
just
pulling
from
a
mutable
tag,
and
one
way
of
doing
that
is
to
have
some
kind
of
data
structure
on
top
of
the
artifacts
that
exist
that
actually
tracks
change
log
or
say
gives
you
an
indication
that,
yes,
we
are
changing,
it's
monotonically
increasing,
and
this
is
the
diff.
F
This
is
the
log
the
this
is
the
source
code
that
it
came
from,
etc,
etc,
etc,
and
if
you
do
not
have
some
kind
of
management
ability
on
in
a
regis
like
built
into
the
registry,
that
would
make
somebody
who
does
not
have
control
over,
say-
or
you
know
does
not
have.
I
guess,
like
top-down
authority
like
justin,
has
to
be
able
to
go
and
say,
okay,
go
and
implement
this.
B
Justin's
justin's
proposal
is
not
no,
he
definitely
doesn't
have
top-down
power.
I
think
people
just
respect
justin,
because
he's
got
he's
a
smart
person
and
he
and
he
has
an
idea
of
a
way,
a
data
model
that
would
solve
a
lot
of
the
problems.
We've
seen
he's.
Definitely
not
the
the
oci
supreme
dictator
or
anything
like
that,
but
I
I
think
these
things
are
good.
F
Like
you
know,
okay,
like
full
disclosure,
I'm
an
architect
at
an
up-and-coming
cloud
provider,
and
I
have
grand
visions
as
well,
but
the
reason
why
I'm
here
in
this
working
group
is
to
be
able
to
figure
out
how
this
grand
vision
overlaps
with
what
exists
right
now
and
how
to
like
you
know,
do
the
as
the
saying
goes,
like
the
big
tides,
what
big
wave
pulls
up
boats
or
something
like
that
rising
tide
lifts
all
boats.
There
we
go
so
I
mean.
F
B
I
think
there's
there's
two
things
here.
I
think
there's
solving
for
specific
use
cases
where
we
have
commonalities.
So
in
this
case,
from
what
I
mean,
I
I
got
involved
very
late
in
this,
so
I'm
also
not
the
right
person
to
answer
these
questions,
but,
like
this
working
group
from
what
I
understand
is
to
kind
of
solve
a
specific,
a
specific
set
of
use
cases.
Where
we've
seen
this,
we
need
to
reference
different
objects.
B
B
I
don't
think
this
working
group
should
dictate
necessarily
how
signatures
are
done,
although
that
is
a
a
good
use
case
to
to
test
on
or
how
s
bombs
are
stored.
I
think
those
two
things
are
kind
of
adjacent,
but
how
to
reference
things
and
connect
them
up.
It
should,
in
terms
of
like
the
meta,
how
should
data
struct
be
structured
inside
registries
in
the
future?
I
think
that
should
go
straight
to
the
top
of
the
oci
and
they
should
have
that
discussion
there
and
the
way
to
get
engaged
engaged
there.
B
I
think,
is
to
go
to
the
oci
meetings
and
ask
that
question
there.
This,
like,
I,
don't
think
it's
I
mean
this
working
group-
could
raise
the
complaints.
For
example,
we
can
raise
the
things
of
like
we
want
oci
index
editing
to
be
atomic
because
it
breaks
our
use
case
here,
like
I
think,
that's
a
valid
thing
to
raise
up,
but
I
don't
think
if
we
go
to
them
and
say
we
would
like
to
redo
the
entire
registry
architecture
because
it
would
solve
our
problems.
B
That's
a
good
approach
because
it
would
be
it
would
solve
our
problem,
but
it
wouldn't
it
kind
of
goes
much
bigger
than
we
need
to
solve
that
problem.
I
think
so.
I
would
take
the
bigger
stuff
to
the
to
the
oci
that,
like
the
I
know,
what's
called
the
tab
or
toc
and
see
what
they
what
they
say.
D
Yeah
we
we
have
a
couple
of
tob
oci,
tob
people,
including
josh
and
nisha.
I
think,
if
to
the
question
of
like
how
do
you
motivate
people
to
let
you
innovate
things?
I
think
there
are
two
proven
ways
with
examples
and
one
proven
bad
way
with
examples.
D
One
of
the
ways
is
to
just
go
build
the
thing
yourself
in
a
vacuum
iterate
on
it
show
that
it
works,
show
that
it's
good
and
if
it's
good
and
people
agree
with
you,
then
you
know,
customers
will
beat
a
path
to
your
door
and
docker
will
implement
it
in
hub
and
azure
will
implement
it
in
an
acr,
et
cetera,
et
cetera
the
example
for
that
one
is
docker
hub.
They
just
invented
the
api
one
day
and
it
worked
well
enough
that
people
used
it
and
then
it
got.
D
D
It's
imperfect
everyone
kind
of
dislikes
the
warts,
but
it
exists
and
works
today
and
doesn't
require
any
change,
so
everyone
has
opted
into
supporting
it
just
by
virtue
of
running
a
registry.
D
A
one
way
that
doesn't
work
is
to
sit
in
a
room
with
a
bunch
of
other
smart
people
and
come
up
with
the
ideal
scenario
and
say
oci
says
this
is
the
way
to
run
registry,
v2
or
v3
or
v5
or
6
or
whatever,
and
then
use
that
to
say
you
know,
google,
you
have
to
implement
this
api
now
or
amazon.
You
have
to
implement
this
api
now
like
they
just
won't
they
just
you
know,
especially
if
v1
works,
fine
or
v2.
D
You
know
the
current
existing
oci
spec
works,
fine,
they're
not
going
to
do
it
without
a
reason
to
do
it,
so
I
would
say-
and
you
don't
need
oci's
permission
to
go-
write
your
own
implementation
of
a
graph
based
registry
or
whatever
you
want.
It
just
means
you'll
be
doing
a
lot
of
work
alone
that
might
be
rejected
or
bike
shedded
later
by
other
people,
but
that's
sort
of
just
how
it
goes
right.
D
D
B
Yeah,
the
key
piece
is,
you
have
to
get
consensus
and
build
consensus
around
ideas,
and
if
you
don't,
then
they
don't
succeed,
and
so
it
can
be
the
best
technical
solution.
But
if
you
don't
have
users
behind
you
and
other
people
with
you
who
can
implement
it,
then
it
dies.
It's
it's
a
good
and
a
bad
thing.
I
guess,
but
it's
it's
just
how
it
works.
D
So
I
do
think
we're
pretty
far
off
topic.
Does
anybody
have
anything
they
want
to
talk?
Were
there
was
there
more
sort
of
officially
stated
business
about
reference
types,
I'm
more
than
happy
to
keep
reminding
folks
that
we
need
a
proposal
f,
but
I
think
they
know.
D
I
think
I
think
they
know
it.
Otherwise.
I
think
we'll
just
wait
for
that
and
talk
about
that
next
time
or
whenever
I.
C
B
It's
us.
I
know
I
was
just
trolling
because
I'm
saying
who
needs
to
be
reminded,
it's
us
it's.
I
managed
to
get
myself
covered,
which
is,
I
do
not
recommend
one
star
experience
and
the
also
I've
got.
I
manage
a
lot
of
people,
so
I've
got
a
lot
going
on
some
of
that.
I'm
gonna
get
this
advantage
to
help
me
draft
some
of
this
and
get
it
going
forwards.
I
also
found
that
the
discussion
on
the
issue
was
actually
super.
F
If
you
need
any
help
with
that,
I
think
this
group
would
be
happy
to
help
out.
B
Yeah,
I
think
we'll
throw
something
together
and
then
and
then
share
it
in
the
channel
and
get
some
feedback
and
then
it's
raising
it.
That
way,
hopefully.
F
But
I
can
tell
you
just
because
I've
submitted
a
proposal
that
was
the
with
no
no
deep
knowledge
of
any
of
this
stuff
that
it
is
like
pretty
straightforward
to
do.
You
don't
have
to
put
much
research
into
it.
C
B
B
That's
what
we
want
and,
as
I
said
in
the
initial
thing
like
nobody's
gonna
search
to
josh's
point
nobody's
gonna,
be
super
stoked
with
it,
but
I
think
that's
the
it's
the
you
know
in
the
list
of
trade-offs.
We
have
to
make
redesigning
registries
all
the
way
down
to
find
something
that
works.
Hopefully,
we'll
find
something
that
kind
of
makes
sense.