distributable and decentralized values

[Vincent Batts]

The topic of distribution of bundles has come up now. And I hope that
it is clear that we're driving that the OCI bundles _can_ be
distributed, but not driving the _how_. This includes separating host
only config/state etc.

Brandon outlined many points in his harmonization post
(https://groups.google.com/a/opencontainers.org/d/msg/dev/uo11avcWlQQ/EzQVIGhhEAAJ).
I'd like to put together an effort for next steps of letting these
distributable bundles actually be decentralized. The immediate
implications of this are:
* that a bundle-publisher-identity can delegate a location for a
bundle to be discovered
* that discoverable bundle has an attestable identity of its own

For many, this is quickly sounding like implementations of _how_ this
can be done. I'm wondering what primitives could be declared that
allow implementations and higher level tooling build out the _how_,
but have solid basics.

There is mix of x.509 CA framework and leverage of DNS SRV and/or TXT
records to give authority, where abouts and information of
bundle-publisher-identity.
And a fileset verification of a rootfs that is cryptographically safe,
and will not interfere with implementations like layering or platform
specific VFS semantics.

Thoughts?

vb

[Brandon Philips]

I think a step to getting to a bundle-publisher-identity delegation is to start adding metadata to the config.json for naming. Then a user can use the name to find the bundle and verify the bundle name in the config.json after fetching and before running. I worked up a branch that adds a name which is a first step.

The basic idea from the commit message:

To identify bundles lets add a name field to the config.json with a URL-like structure. The field should be descriptive and human readable and give a user indication on the application inside the bundle. We will use a URL-like structure to facilitate discovery of bundle images in the future. For example all of the following are all valid names: 

    example.com

    example.com/app

    example.com/org/app

    subdomain.example.com/org/project/app

This leaves room for future use cases while giving existing use cases like Docker images a simple mapping from existing names e.g. index.docker.io/group/my-app.

The branch is here and if we have rough agreement on the approach I will post a PR up:

https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4

Brandon

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

[Stephen Day]

The best approach here would be to have a few manual examples of distributing a bundle. For example, one could show distribution using a tar, rsync or an rpm.

I'm still not sure what we really want from identity. I have been playing with a fileset verification system that would be adequate, but the cost of verification is expensive over a general filesystem and relies on transport verification.

A lot of the features you describe are hard or flaky without defining a common bundle artifact. The question is really whether or not we want to define such a format as part of runc.

Perhaps, we can focus on providing that stable, host agnostic filesystem layout as the base for content distribution and work from there.

Sent from my iPhone

[Vincent Batts]

Understandable. Rpm and debs have solved some this. And their verification (I.e. `rpm -qV ...`) are not terribly expensive. Tar archives are nice and awful, though working on tar-split, I've seen how it wouldnt be a big undertaking to have fileselt-like entries for speed validation. Though these are implementation approaches.

I don't think the features are so much "hard" as just step removed from where the focus is. There can be primitives leveraged that should enable this. It's just drawing out these base requirements for these OCI values.

[Stephen Day]

My point is that we should come up with a few uses cases that can validate that runc provides a sufficient base to build upon. This practice should identify the gaps and inform us about what is critical and what can be deferred to a higher level of the specification.

Digressing, my work on a format agnostic fileset implementation has been encouraging. Though I disparaged the performance below, my non-optimized toy implementation performs acceptably.

Sent from my iPhone

[W. Trevor King]

On Fri, Aug 28, 2015 at 04:35:56PM -0400, Vincent Batts wrote:
> I'd like to put together an effort for next steps of letting these
> distributable bundles actually be decentralized. The immediate
> implications of this are:
>
> * that a bundle-publisher-identity can delegate a location for a
> bundle to be discovered
> * that discoverable bundle has an attestable identity of its own
>
> For many, this is quickly sounding like implementations of _how_
> this can be done. I'm wondering what primitives could be declared
> that allow implementations and higher level tooling build out the
> _how_, but have solid basics.

As I've mentioned before [1,2,3], you can *already* do all this with
IPFS. To sketch it out in more detail (with IPFS v0.3.7), I can
publish (from [4]):

publisher$ git clone --branch ipfs-gateway git://github.com/wking/oci-gentoo-minimal.git
publisher$ cd oci-gentoo-minimal
publisher$ ipfs add -r .
…
added QmdHkJ5wC9MZC2orMYhoXSDwK7kYFXSoASC5kWFrWHt7ko .
publisher$ ipfs daemon

And anyone who wants can download and run:

user$ ipfs daemon
user$ ipfs get -o ipfs-gateway /ipfs/QmdHkJ5wC9MZC2orMYhoXSDwK7kYFXSoASC5kWFrWHt7ko
Saving file(s) to ipfs-gateway
33.34 MB 0
user$ killall ipfs # stop the old daemon to free up the ports for the gateway
user$ cd ipfs-gateway
user$ make
sudo chown -R root:root rootfs root
sudo chmod 755 runc rootfs/bin/* rootfs/lib64/*
sudo ./runc config.json
running!
initialize IPFS node
…
Gateway (readonly) server listening on /ip4/0.0.0.0/tcp/8080

So that's distribution and cryptographic validation (assuming you
trust the IPFS path, more on that later) whenever you want for every
file in the bundle.

If you want an attestable identity with distributed delegation, just:

publisher$ >name.json <<EOF
> {
> "name": "wking/oci-gentoo-minimal v0.1",
> "ocsBundle": "/ipfs/QmdHkJ5wC9MZC2orMYhoXSDwK7kYFXSoASC5kWFrWHt7ko"
> }
> EOF
publisher$ gpg --detach-sign name.json

or whatever you like, and then push that to anybody with a lookup
service. The user will hit her favorite lookup service, fetch all the
names and signatures which claim to be for wking/oci-gentoo-minimal
v0.1, and run:

user$ gpg --verify name.json.sig
gpg: Signature made Sat 29 Aug 2015 03:28:02 AM PDT using RSA key ID A051B1AC
gpg: Good signature from "William Trevor King <wk...@tremily.us>" [ultimate]
…

as part of deciding which IPFS path to fetch. Keep the signed name
around after fetching and recheck its validity whenever you doubt an
unsigned IPFS path is accurate, or want to know which IPFS objects to
lookup to check a particular file:

Has anyone you don't trust corrupted the name?

user$ gpg --verify name.json.sig
gpg: Signature made Sat 29 Aug 2015 03:28:02 AM PDT using RSA key ID A051B1AC
gpg: Good signature from "William Trevor King <wk...@tremily.us>" [ultimate]
…

No. Link the name to an IPFS path:

user$ cat name.json
{
"name": "wking/oci-gentoo-minimal v0.1",
"ocsBundle": "/ipfs/QmdHkJ5wC9MZC2orMYhoXSDwK7kYFXSoASC5kWFrWHt7ko"
}

Is my rootfs/bin/busybox uncorrupted?

user$ ipfs object get /ipfs/QmdHkJ5wC9MZC2orMYhoXSDwK7kYFXSoASC5kWFrWHt7ko/rootfs/bin | jq --raw-output '.Links[]|select(.Name == "busybox").Hash'
QmfBYD5Yxin1uQUdStMq2h3YttrzV3aD2qUjbXg25jezi3
user$ ipfs add --quiet --only-hash rootfs/bin/busybox
QmfBYD5Yxin1uQUdStMq2h3YttrzV3aD2qUjbXg25jezi3

That seems to cover everything for me. What sort of functionality do
you envision writing that's not in that example?

IPFS is designed to make this sort of distributed distribution and
verification easy (and we haven't even gotten into IPNS), so I have no
personal need for OCI-side X.509, DNS records, fileset verification,
etc. There are many reasonable validation/distribution schemes, but
opencontainers/specs is currently nicely scoped to only cover “what
does the bundle-author need to do to create a bundle that an
OCS-compliant runtime can create/start/stop” [5], and *that* is
something that everyone writing OCS-compliant runtimes or bundles for
them will be interested in ;).

Of course, I don't mind if other folks want to cook up their own
non-IPFS system and spec that out as a separate OCI project [1]. But
I don't think we should be blessing one distribution approach (or
ground work for it) and stuffing it into opencontainers/specs.

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/uo11avcWlQQ/Tn0nFymREAAJ
From: W. Trevor King
Subject: Re: appc + oci harmonization progress
Date: Thu, 13 Aug 2015 11:29:08 -0700
Message-ID: <2015081318...@odin.tremily.us>
Cc: d...@opencontainers.org
[2]: https://github.com/opencontainers/specs/issues/5#issuecomment-115423504
[3]: https://github.com/opencontainers/specs/pull/76#issuecomment-124913227
[4]: https://github.com/wking/oci-gentoo-minimal/commit/54993cebfdf0d2b3c2cd23e826bab6aa854c6ae7
https://github.com/wking/oci-gentoo-minimal/tree/ipfs-gateway-v0.1
[5]: https://github.com/opencontainers/specs/blob/6a5a4454655b4ffacbba11d50471817bc11ed36c/runtime.md#lifecycle

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[Vincent Batts]

I don't dislike IPFS, but that is a way of how to distribute bundles. And one that requires setup by clients and has its own discoverability integration.
To my point, were there some primitives that could allow a discoverable pointer to an IPFS distribution of images. It would then be up to you of bubbling up the cryptographic identity of a container, so it is discoverable, because despite the trust assumption in IPFS, others would need to validate this.

vb

[W. Trevor King]

On Sat, Aug 29, 2015 at 07:57:40AM -0400, Vincent Batts wrote:
> I don't dislike IPFS, but that is a way of how to distribute
> bundles.

Isn't that what we're talking about here? What else are you
interested in distributing? Or are you just asking for a more
thorough sketch of a discoverablility system? I just mentioned
“lookup service” in my last post [1], but hadn't gone into detail
about what I thought such a service should look like (because I don't
think that a lookup-service will impact the OCS bundle-content). If
more detail would be helpful, just let me know.

> And one that requires setup by clients…

I agree that IPFS doesn't have the userbase that cURL does ;), but I
think “install IPFS [2] and runC, launch a local IPFS daemon to fetch
remote bundles, and use runC to launch bundles” is only more intrusive
than runC-only because you'd have to either leave the IPFS daemon
running or spin it up when you wanted to fetch. That is extra work,
but it's pretty much the same as running a Docker daemon, and there
haven't been uptake problems there. Folks interested in making it
transparent could wrap IPFS and runC together in a single binary that
auto-launched the daemon as needed (or whatever seemed more usable).

> … and has its own discoverability integration.

Discovery seems orthogonal to distribution and validation to me, so
I'd consider this a win ;).

> To my point, were there some primitives that could allow a discoverable
> pointer to an IPFS distribution of images. It would then be up to you of
> bubbling up the cryptographic identity of a container, so it is
> discoverable, because despite the trust assumption in IPFS, others would
> need to validate this.

I'm having trouble parsing this. My guess is that you mean something like:

Assuming you have a registry that lets you discover a name ↔
IPFS-path assertion that you trust, the client would still have to
confirm that the locally unpacked filesystem matches the one the
signer intended.

I see a few possible verification questions:

a. Trusting the cryptographic security of an IPFS Merkel tree.
b. Trusting IPFS to download the correct object tree associated with
the bundle's IPFS path (“am I fetching what I asked for?”).
c. Verifying that the locally-unpacked bundle matches the filesystem
specified by the bundle's IPFS path (“does my on-disk filesystem
match what I asked for?”).

It sounds like you're asking about (c), but I gave one approach to
that in the “Is my rootfs/bin/busybox uncorrupted?” portion of my
previous post [1]. Maybe if you sketched out an example of a client
performing the verification you're wanting in another context, I can
try to figure out how that question would be answered in an IPFS
context?

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/h_sYNGFiFQAJ
Message-ID: <20150829110...@odin.tremily.us>
[2]: http://ipfs.io/docs/install/

[Brandon Philips]

On Sat, Aug 29, 2015 at 4:57 AM Vincent Batts <vba...@gmail.com> wrote:

I don't dislike IPFS, but that is a way of how to distribute bundles. And one that requires setup by clients and has its own discoverability integration. 

Right, I think we need to tackle the discoverability first and define how bundles are named to support discovery. Distributing bundles via whatever transport (ipfs, s3, nfs, etc) is desirable but defining a namespace is where I believe we should start.

Using the URL-like method I suggested earlier (e.g example.com/app) is similar to how the Golang package namespace works and allows for an uncoordinated distributed namespace with delegation to object hosting[1]. So, you could imagine GETting https://example.com/app?oc-get=1 and finding the ipfs path in a meta tag (or https, or bittorrent, etc).

Brandon

[1] http://golang.org/cmd/go/#hdr-Remote_import_paths

[Solomon Hykes]

Personally I think naming/trust/discovery is going to be really hard to specify in a way that makes everyone happy, and should remain out of scope. For example ipfs is designed to not depend on DNS for naming. If we specify that dns *must* be used, does that make ipfs non-compliant? As another example, Docker registries and the Docker image format do not map 1-1 to container bundles. They may carry additional, Docker-specific metadata and artifacts, and may for example bundke multiple containers in a single image. I'm guessing something similar could be done with the RPM format for example.

I would like to remind everyone that the task of this group is to define a portable runnable format - "the ELF of containers" which can be packaged and distributed in many ways. Our task is not to specify yet another packaging and distribution system. Naming and discovery are a packaging concern, and we should resist the temptation to choose the "one and true way". That would be a clear case of feature creep and would stretch us too thin. We have plenty of work left defining a solid executable format, let's focus on that!

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

[Vincent Batts]

On Aug 30, 2015 6:45 PM, "Solomon Hykes" <solomo...@docker.com> wrote:
>
> Personally I think naming/trust/discovery is going to be really hard to specify in a way that makes everyone happy, and should remain out of scope. For example ipfs is designed to not depend on DNS for naming. If we specify that dns *must* be used, does that make ipfs non-compliant? As another example, Docker registries and the Docker image format do not map 1-1 to container bundles. They may carry additional, Docker-specific metadata and artifacts, and may for example bundke multiple containers in a single image. I'm guessing something similar could be done with the RPM format for example.

Correct that some packages have reinvented the wheel, but that wheel has similar characteristics.
The discussion of backwards-compat vs. "non-compliance" is definitely something to discuss.
Though, ipfs doesn't require dns, having something like the DNS TXT record, which is for attestible arbitrary pointers (see vspf mail entries) a publisher could have a pointer to their ipfs information, or Docker registry.
For docker additional metadata, I don't think that should rule out that the base bundle include OCI configuration.

> I would like to remind everyone that the task of this group is to define a portable runnable format - "the ELF of containers" which can be packaged and distributed in many ways. Our task is not to specify yet another packaging and distribution system. Naming and discovery are a packaging concern, and we should resist the temptation to choose the "one and true way". That would be a clear case of feature creep and would stretch us too thin. We have plenty of work left defining a solid executable format, let's focus on that!

The runtime is a thin piece that is heavy focused on, but true to the tenent values of the OCI charter it extends beyond just that elf runtime. If we don't have the semantics around supporting OCI roots and to enable further innovation with a common vocabulary, then relevance of a coomon format won't be broadly received. This isn't scope creep, it is following the charter.
As we are hoping to have a draft of the release out soon, if these thoughts are not considered, it may have negative impact later.

vb

[W. Trevor King]

On Sun, Aug 30, 2015 at 07:03:58PM -0400, Vincent Batts wrote:
> As we are hoping to have a draft of the release out soon, if these
> thoughts are not considered, it may have negative impact later.

I think developing your discovery and/or distribution specs in a
separate repository or repositories (opencontainers/distribution?) is
the best of both worlds. You get space to flesh out your distribution
and discovery protocol, and can push any bundle-impacting changes back
towards opencontainers/specs with a link back to (for example) an
opencontainers/distribution issue explaining why the current spec
doesn't allow some important distribution or discovery task. Then the
rest of us that are just interested in the spec can chime in with
thoughts about how the proposed bundle change impacts the systems
where we use OCS bundles (which may not include anything built on
opencontainers/distribution).

Cheers,
Trevor

[Solomon Hykes]

On Sunday, August 30, 2015, Vincent Batts <vba...@gmail.com> wrote:

On Aug 30, 2015 6:45 PM, "Solomon Hykes" <solomo...@docker.com> wrote:
>
> Personally I think naming/trust/discovery is going to be really hard to specify in a way that makes everyone happy, and should remain out of scope. For example ipfs is designed to not depend on DNS for naming. If we specify that dns *must* be used, does that make ipfs non-compliant? As another example, Docker registries and the Docker image format do not map 1-1 to container bundles. They may carry additional, Docker-specific metadata and artifacts, and may for example bundke multiple containers in a single image. I'm guessing something similar could be done with the RPM format for example.

Correct that some packages have reinvented the wheel, but that wheel has similar characteristics.
The discussion of backwards-compat vs. "non-compliance" is definitely something to discuss.
Though, ipfs doesn't require dns, having something like the DNS TXT record, which is for attestible arbitrary pointers (see vspf mail entries) a publisher could have a pointer to their ipfs information, or Docker registry.
For docker additional metadata, I don't think that should rule out that the base bundle include OCI configuration.

> I would like to remind everyone that the task of this group is to define a portable runnable format - "the ELF of containers" which can be packaged and distributed in many ways. Our task is not to specify yet another packaging and distribution system. Naming and discovery are a packaging concern, and we should resist the temptation to choose the "one and true way". That would be a clear case of feature creep and would stretch us too thin. We have plenty of work left defining a solid executable format, let's focus on that!

The runtime is a thin piece that is heavy focused on, but true to the tenent values of the OCI charter it extends beyond just that elf runtime.

No, it really does not. The whole point of the OCI charter is to keep the scope narrow in order to provide a standard that is a) well designed and b) truly ubiquitous. For this reason the charter explicitly states that the scope should not extend over time.

Since I defined the underlying principles of the charter and later explained them to you, I hope you'll consider my point of view on this topic.

I think the slide I used to introduce the spec at Dockercon was pretty straightforward: "a universal intermediary format for OS containers". The slide before that read "just the runtime and nothing else".

We can provide useful primitives to the many distribution systems out there with a standardized hashing, and a standardized signature attachment format. There is absolutely no need to over-extend.

 If we don't have the semantics around supporting OCI roots and to enable further innovation with a common vocabulary, then relevance of a coomon format won't be broadly received. 

I'm not sure I understand what you mean by "supporting oci roots" and "enable further innovation with a common vocabulary".

This isn't scope creep, it is following the charter. 

I don't know what else to say at this point. Let's just agree to disagree.

As we are hoping to have a draft of the release out soon, if these thoughts are not considered, it may have negative impact later.

I agree, now is the time to carefully consider the risk of scope creep. Remember that no is temporary, but yes is forever...

[Tim Hockin]

On Sun, Aug 30, 2015 at 12:18 AM, W. Trevor King <wk...@tremily.us> wrote:

> I agree that IPFS doesn't have the userbase that cURL does ;), but I
> think “install IPFS [2] and runC, launch a local IPFS daemon to fetch
> remote bundles, and use runC to launch bundles” is only more intrusive
> than runC-only because you'd have to either leave the IPFS daemon
> running or spin it up when you wanted to fetch. That is extra work,
> but it's pretty much the same as running a Docker daemon, and there
> haven't been uptake problems there. Folks interested in making it
> transparent could wrap IPFS and runC together in a single binary that
> auto-launched the daemon as needed (or whatever seemed more usable).

First, we don't want to thrust a solution on people. IPFS is
interesting but (pardon if I misinterpret) is not fully baked nor what
anyone would call "ubiquitous". Aside from that, I also disagree with
the assertion that daemons are not a problem. They are. I have heard
many people say that their primary interest in runc is a daemonless
operating mode.

On Sun, Aug 30, 2015 at 3:45 PM, Solomon Hykes <solomo...@docker.com> wrote:

> example, Docker registries and the Docker image format do not map 1-1 to
> container bundles. They may carry additional, Docker-specific metadata and
> artifacts, and may for example bundke multiple containers in a single image.

I admit that the Docker image and registry are probably the parts I am
least familiar with, but can you clarify this?

> distributed in many ways. Our task is not to specify yet another packaging
> and distribution system. Naming and discovery are a packaging concern, and
> we should resist the temptation to choose the "one and true way".

I don't see this as a bid to define either distribution or packaging,
just an affordance for doing so. That said, I have been known to be a
fan of tight specification, so it's not surprising that the addition
of a well-defined name field works for me.

[Joe Beda]

Hello all,

I've been lurking for a bit now and would like to start helping out and weighing in.

When the OCI was first announced I was most excited about moving the image format and distribution system forward.  From my reading of the charter it seems to be clearly in scope.

Specifically:

• 4.b.i: "Creating and maintaining formal specifications (“OCI Specifications”) for container image formats".  The term "image format" is underdefined but I assume it lines up with the terminology used by Docker as seen with "Docker Image Specification v1.0.0".  This specification also includes fields around naming.
• 6.b: "Decentralized. Discovery of container images should be simple and facilitate a federated namespace and distributed retrieval."

Given that the image format, naming and distribution are all in scope it seems reasonable to start with a DNS based name.  DNS is well understood as a way to bootstrap a distributed namespace.  It is commonly used by systems such as XML (for xml namespaces) and Java and Go.  I'd love to think about other ways to bootstrap a distributed federated namespace if folks have them.  Once we have a working proposal for naming other problems such as verification and discovery can be tackled.

As the OCI values input based on contribution, I'd be happy to start curating the image specification and contribute to a tool set around that specification.

Thanks,

Joe

[W. Trevor King]

On Sun, Aug 30, 2015 at 08:45:14PM -0700, Tim Hockin wrote:

> On Sun, Aug 30, 2015 at 12:18 AM, W. Trevor King wrote:
> First, we don't want to thrust a solution on people. IPFS is

> interesting but…

Right. I'm not saying that we should push IPFS as the one, true
distribution channel. I'm just saying that IPFS works well right now
for distributing OCS bundles, and that leads me to believe that we
don't need to alter the spec to support *other* distribution systems.
At least until we hear a pitch for “distribution $SYSTEM needs
$FEATURE to avoid $ISSUE” [1].

And I agree that I'd be cautious about using IPFS as background
tooling for non-developers until it has a few more years under it's
belt ;).

> Aside from that, I also disagree with the assertion that daemons are
> not a problem. They are. I have heard many people say that their
> primary interest in runc is a daemonless operating mode.

Docker shows that they're not an insurmountable problem, even for
user-run daemons. And somebody is going to be running a daemon in any
distribution system (even if it's just Nginx on docker.com, for
example). If Alice wants to allow Bob to consume IPFS-distributed
containers without Bob running a daemon, Alice can run a (read-only)
daemon on an interface Bob can access, and Bob can just run the client
pointing at Alice's daemon.

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/vy4EQzvZFQAJ
Message-ID: <20150830232...@odin.tremily.us>

[David Liang]

+1

To me, OCI spec looks very much like 'rpm'. 

The delivery/discover system discussed here is just like zypper or yum.

Since we don't have much dependencies between containers, we may take the delivery/discover system as an `appstore`.

In freedesktop, there is an open collaboation service (https://en.wikipedia.org/wiki/Open_Collaboration_Services) , we can use the 'content' module.

If there was any social requirement in the future (rate/downloads), OCS will be a choice. 

Anyway, I don't think we should put the url link into the config.json. That should be done in a higher level.

David

[Brandon Philips]

On Mon, Aug 31, 2015 at 8:33 AM David Liang <liang...@gmail.com> wrote:

To me, OCI spec looks very much like 'rpm'. 

RPM packages have names like "redis-server". Currently the OCI bundle spec does not have a name at all, this discussion is about adding a name to the spec.

Now, we cannot use naming like RPM/DEB because container images needs to have a decentralized namespace? Why? Because, the power of application containers, that has emerged in the last two years, is anyone can easily build and host their software wherever they wish. It flips the distribution model around and lets anyone package and distribute applications and mix-match applications from different authors and sources.

It is no longer "yum install redis-server" which will fetch from a central fedora yum repo but now "oci-fetch redis.io/server v0.7.6" which fetches a container image built and packaged by the redis authors directly. Or perhaps "oci-fetch getfedora.org/redis/server v0.7.6" if the fedora team maintains and packages their own copy of redis. The important thing is the user has a choice and the image authors are free to host under their namespace without coordination.

We need to ensure the specification embraces the distributed nature of the application container image packaging and distribution story and supports this workflow:

A developer wanting to distribute an open container image for their application can build once, cryptographically sign once, and host in a human discoverable location a container image that can execute under any OCI runtime. 

Brandon

[Brandon Philips]

On Sun, Aug 30, 2015 at 8:57 PM Joe Beda <j...@bedafamily.com> wrote:

When the OCI was first announced I was most excited about moving the image format and distribution system forward.  From my reading of the charter it seems to be clearly in scope.

 

Yes, this is my understanding of reading the charter[1] too. From section 4.b.ii the TDC members are charged with "ensuring OCI Specifications incorporate and align to the OCI Values". And included in our values from section 6.d: "Decentralized. Discovery of container images should be simple and facilitate a federated namespace and distributed retrieval."

Given that the image format, naming and distribution are all in scope it seems reasonable to start with a DNS based name. 

Agreed, I would like to hear from more TDC members on their thoughts on adding a name to the bundle config.json, if there is a rough consensus I will put up the patch I posted earlier so we can continue discuss the finer points on GitHub.

Thank You,

Brandon

[1] https://github.com/opencontainers/web/blob/33bc0b2597cbfd37e4728660d4b74272603b6f97/content/charter.md

[Solomon Hykes]

On Mon, Aug 31, 2015 at 10:03 AM, Brandon Philips <brandon...@coreos.com> wrote:

On Sun, Aug 30, 2015 at 8:57 PM Joe Beda <j...@bedafamily.com> wrote:

When the OCI was first announced I was most excited about moving the image format and distribution system forward.  From my reading of the charter it seems to be clearly in scope.

 

Yes, this is my understanding of reading the charter[1] too. From section 4.b.ii the TDC members are charged with "ensuring OCI Specifications incorporate and align to the OCI Values". And included in our values from section 6.d: "Decentralized. Discovery of container images should be simple and facilitate a federated namespace and distributed retrieval."

Yes, the OCI specification should allow for distribution and discovery to be decentralized. That doesn't mean it should specify a single method of distribution and discovery. If you specify a standardized method for 1) hashing and 2) attaching signatures, you remove the hard dependency on DNS (a centralized naming system) and give more flexibility to consumers of the standard (we already discussed in this thread several examples of distribution and discovery which would become incompatible with OCI, for not good reason, should it expand its scope to discovery and distribution).

In short: by specifying a single mandatory discovery and naming system, you actually hurt decentralized designs.

I would also like to point out that OCI also has a value of Minimalism, which I believe this proposal is violating. I am really worried that we are trying to do too much.

Given that the image format, naming and distribution are all in scope it seems reasonable to start with a DNS based name. 

Agreed, I would like to hear from more TDC members on their thoughts on adding a name to the bundle config.json, if there is a rough consensus I will put up the patch I posted earlier so we can continue discuss the finer points on GitHub.

I am in violent disagreement. So clearly there is no consensus here.

[Vincent Batts]

On Mon, Aug 31, 2015 at 1:15 PM, Solomon Hykes <solomo...@docker.com> wrote:
> On Mon, Aug 31, 2015 at 10:03 AM, Brandon Philips
> <brandon...@coreos.com> wrote:
>>
>> On Sun, Aug 30, 2015 at 8:57 PM Joe Beda <j...@bedafamily.com> wrote:
>>>
>>> When the OCI was first announced I was most excited about moving the
>>> image format and distribution system forward. From my reading of the
>>> charter it seems to be clearly in scope.
>>
>>
>> Yes, this is my understanding of reading the charter[1] too. From section
>> 4.b.ii the TDC members are charged with "ensuring OCI Specifications
>> incorporate and align to the OCI Values". And included in our values from
>> section 6.d: "Decentralized. Discovery of container images should be simple
>> and facilitate a federated namespace and distributed retrieval."
>
>
> Yes, the OCI specification should allow for distribution and discovery to be
> decentralized. That doesn't mean it should specify a single method of
> distribution and discovery. If you specify a standardized method for 1)
> hashing and 2) attaching signatures, you remove the hard dependency on DNS
> (a centralized naming system) and give more flexibility to consumers of the
> standard (we already discussed in this thread several examples of
> distribution and discovery which would become incompatible with OCI, for not
> good reason, should it expand its scope to discovery and distribution).
>
> In short: by specifying a single mandatory discovery and naming system, you
> actually hurt decentralized designs.

That is less of my original point. and I hope this is not getting
conflated due to tensions and expectations.

Stepping back a bit, there are primitives of DNS, that allow hosting
delegation, but still traceability of ownership. Further constructs
have built on this, like https and CA etc. From here there is the
world of the internet. There is no dictation of the services required
to run on this. But to not leverage this is foolish. Without examples
of how this existing framework will actually hurt decentralized
designs, that statement is inciting F.U.D., which is actually hurtful.

It is by having declared language around this that we can facilitate
strongly federated naming, and get of of the way other's innovation

[Solomon Hykes]

Vincent, respectfully I don't believe there is any "fud" here, only disagreement.

Example 1: IPFS has a naming system called IPNS. It is detached from DNS by design. It is in use today by Docker users, as an alternate means of distributing Docker images. How will ipfs comply with a requirement to use DNS?

Example 2: Distributing images via bittorrent DHT and trackers. Also detached from DNS. Also in use today to distribute images. How will bittorrent comply with this requirement?

Example 3: Regular Docker registries. Uses a common discovery and distribution system for various content, not limited to OCI-type containers. How will Docker comply with this requirement without duplicating its existing discovery and distribution system?

 

Example 4: RPM and DEB. Uses a naming and distribution system detached from DNS. It seems like an obvious use case to package OCI containers in RPMs and DEBs, and use existing infrastructure to distribute them. How will existing RPM and DEB distribution infrastructure comply with this requirement without ripping out?

Example 5: Namecoin is a popular naming system based on the bitcoin blockchain. There are several threads in the Docker community about using it as a discovery system for images. It is detached from DNS by design. How will it comply with this requirement?

It is by having declared language around this that we can facilitate
strongly federated naming, and get of of the way other's innovation

I understand the temptation to design yet another naming and discovery system. But the reality is that there are thousands of naming systems in this industry, and it is unrealistic to expect everyone to switch to this one. All we will achieve is this: https://xkcd.com/927/ 

I think if you're really set on converting the world to a new naming scheme for the discovery and distribution of content, maybe you should do it in a separate group, and let this one focus on "building a vendor-neutral, portable and open specification and runtime that deliver on the promise of containers as a source of application portability".

[Singh, Deepak]

Taking another step back.

Are we all in agreement with 'A developer wanting to distribute an open container image for their application can build once, cryptographically sign once, and host in a human discoverable location a container image that can execute under any OCI runtime. ‘?  Getting agreement there sounds like the first step.

Assuming that it would be great to have the TDC weigh in, followed by a discussion around the PR.  Conceptually having some flexibility in the distribution and naming system fits in with how application software providers view the world.

[Solomon Hykes]

On Mon, Aug 31, 2015 at 10:40 AM, Singh, Deepak <dees...@amazon.com> wrote:

Taking another step back.

Are we all in agreement with 'A developer wanting to distribute an open container image for their application can build once, cryptographically sign once, and host in a human discoverable location a container image that can execute under any OCI runtime. ‘?  Getting agreement there sounds like the first step.

I think that is too broad of a statement to get a useful agreement on.

I would prefer that we start with the concrete usage examples I listed in my previous email, and agree that these use cases are legitimate should be supported by the OCI, instead of made impossible.

[Tim Hockin]

On Mon, Aug 31, 2015 at 10:38 AM, Solomon Hykes
<solomo...@docker.com> wrote:

I feel like you're attacking a strwa man here, or at perhaps I
misinterpret the original idea.

>How will ipfs comply with a requirement to use DNS?

> How will bittorrent comply with this requirement?

> How will Docker comply with this requirement without duplicating its existing discovery and distribution system?

> How will existing RPM and DEB distribution infrastructure comply with this requirement without ripping out?

> How will it comply with this requirement?

I don't think anyone is saying there's a requirement to use DNS. I
think the proposal was to provide a name for a bundle and to spec the
format of that name in a way similar to a known-workable model (Go
packages)

I'm not sure why it's controversial, personally.

[W. Trevor King]

On Mon, Aug 31, 2015 at 01:26:35PM -0400, Vincent Batts wrote:
> Stepping back a bit, there are primitives of DNS, that allow hosting
> delegation, but still traceability of ownership.

There's also IPNS, which allows namespace delegation (everything under
/ipns/{pubkey-hash} belongs to the owner of the associated private
key). That's like DNS, except there's no need for registrars to
assign sections of the namespace (e.g. no one assigning a registrar
for *.us, and no *.us registrar assigning names under that namespace).
And I'm sure there are many other namespace-delegation systems, both
with and without registrars. Picking DNS would make all those other
namespace-delegation systems second-class citizens for OCS-bundle
discovery.

> Further constructs have built on this, like https and CA etc. From
> here there is the world of the internet.

HTTPS and CA are nice, but not the only way to do things ;).

> But to not leverage this is foolish. Without examples of how this
> existing framework will actually hurt decentralized designs, that
> statement is inciting F.U.D., which is actually hurtful.

Brandon's proposal [1] requires URL-like names to allow folk to
discover metadata via DNS, HTTPS, and “the usual” root CA set. But if
I was operating in an IPFS environment, I'd be better served by a name
like:

/ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7/oci-gentoo-minimal

so folks could hit my IPNS namespace to get up-to-date information on
the bundle (e.g. links to new releases).

And maybe I want to decouple the naming from the bundle, so I can, for
example, switch domain names (or get a new IPNS key) and still link
people to the same bundle hash (so they could easily check that I'd
just moved the metadata, and not inserted something nefarious in the
bundle itself).

These aren't impossible with Brandon's proposal. I could use a name like:

example.com/ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7/oci-gentoo-minimal

and folks who wanted to check for insertions after a name change could
compare the top-level hashes between the bundles, see that only
config.json had changed, and diff the configs to see that only the
name had changed. But those are both annoying enough to have me
preferring that thes naming semantics were landing from a higher level
spec than the OSC.

Cheers,
Trevor

[1]: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4

[Patrick Chanezon]

Distribution and naming of images is in scope for CNCF, not OCI.

https://cncf.io/about/our-mission

OCI is about the image format once it's laid out on disk by a distribution mechanism, that is out of scope of the spec.

From OCI charter https://www.opencontainers.org/charter/

"The Open Container Initiative does not seek to be a marketing organization, define a full stack or solution requirements, and shall strive to avoid standardizing technical areas undergoing signification innovation and debate."

4.b.x scope

"x. Ensuring that the scope of technologies promulgated and proposed as standard elements of OCI Specifications of OCI Projects are those that are sufficiently widespread and sufficiently mature and stable so as to warrant establishment as a standard;"

P@

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

[Joe Beda]

I don't think that DNS *must* be the way to specify a name but it seems like a reasonable place to start.

I think we are conflating naming and discovery.  We can use DNS as a base for naming without requiring it to be used for distribution.  We can easily map these names into something that can co-exist with DNS.  To address your specific examples:

• IPNS -- the base namespace for IPNS seems to be based on the hash of your public key.  This can easily be translated into a DNS name with something like "<peer_id>.ipfs.io"
• DHT -- The DHT is a way to look around and find information based on a name.  It is a transport mechanism not a naming mechanism.  Bittorrent itself doesn't define a namespace but instead just includes a set of hashes that are used to identify chunks (see the definition of the metainfo file).
• Regular Docker registries -- This is easy -- all existing Docker images would just be put under the docker.com domain.  This is an implied part of the name currently regardless.  Non-docker clients would require users to use the fully qualified name.
• RPM and DEB -- these are not federated namespaces.  The whole 'docker' vs 'docker-io' thing with debian shows the limitations of a namespace like this.
• Namecoin looks great.  There is already an adaptation to this using the .bit domain.  There are security issues here with respect to name squatting with no appeals process but that is the nature of something like this.

An alternative would be to use a URN here for naming and allow different schemes.

• urn:oci:ipfs:...
  
• urn:oci:docker:...
  
• urn:oci:deb:...
  
• urn:oci:dns:foo.example.com:...
  

Discovery methods and ease of use might be different depending on each of these.

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

[Vincent Batts]

Correct. This is not a "to DNS or not to DNS" requirement. If that was
the impression, that missed the point.

With these non-dns examples, there is a vocabulary we can arrive at
that accommodates these use-cases and but allows primitives for actual
federated namespaces.

[Vincent Batts]

On Mon, Aug 31, 2015 at 1:51 PM, Patrick Chanezon
<patrick....@docker.com> wrote:
> Distribution and naming of images is in scope for CNCF, not OCI.
> https://cncf.io/about/our-mission

CNCF doesn't enter to this conversation. At beast it will utilize and
lean on OCI for the primitives of this discussion.

> OCI is about the image format once it's laid out on disk by a distribution
> mechanism, that is out of scope of the spec.
> From OCI charter https://www.opencontainers.org/charter/
> "The Open Container Initiative does not seek to be a marketing organization,
> define a full stack or solution requirements, and shall strive to avoid
> standardizing technical areas undergoing signification innovation and
> debate."
> 4.b.x scope
> "x. Ensuring that the scope of technologies promulgated and proposed as
> standard elements of OCI Specifications of OCI Projects are those that are
> sufficiently widespread and sufficiently mature and stable so as to warrant
> establishment as a standard;"

These statements are not directly applicative, except in saying,
specifications should lean on widely used standards. And that is what
I'm expecting we draw from in pursuit of following the values laid out
in the OCI charter.

[W. Trevor King]

On Mon, Aug 31, 2015 at 11:06:52AM -0700, Joe Beda wrote:
> - IPNS
> <https://github.com/ipfs/examples/tree/master/examples/ipns> --

> the base namespace for IPNS seems to be based on the hash of your
> public key. This can easily be translated into a DNS name with
> something like "<peer_id>.ipfs.io"

Is that going to be a special-case that all clients know about?
Otherwise what happens if the owners of iofs.io or the *.io DNS
registrar decide to serve something at https://<peer-id>.ipfs.io?

> An alternative would be to use a URN here for naming and allow different
> schemes.
>

> - urn:oci:ipfs:...
> - urn:oci:docker:...
> - urn:oci:deb:...
> - urn:oci:dns:foo.example.com:...

>
> Discovery methods and ease of use might be different depending on
> each of these.

This puts everyone on a more even footing (and avoids the DNS-or-not
confusion about something like <peer-id>.ipfs.io. But putting it
inside the bundle means you'd still need a new bundle if you wanted to
change a metadata location, and there would be no way to offer several
parallel locations [1,2].

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/r_x7cmwVFgAJ
Message-ID: <20150831174...@odin.tremily.us>
[2]: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4#commitcomment-12981584

[crai...@google.com]

FWIW I support Deepak's earlier statement.  

I also support the idea that naming and discovery are somewhat orthogonal, but that DNS model represents a good starting point to address naming.

I think it is really important that these topics are addressed in OCI, and not in CNCF fwiw.  It is important that the OCI forum covers standardization of image and runtime environment;  if the OCI charter as currently stated does not make provisions for this, we as a community should open that up to broader discussion through LF.

-- craig

[Joe Beda]

On Mon, Aug 31, 2015 at 11:20 AM, W. Trevor King <wk...@tremily.us> wrote:

On Mon, Aug 31, 2015 at 11:06:52AM -0700, Joe Beda wrote:
>    - IPNS
>    <https://github.com/ipfs/examples/tree/master/examples/ipns> --
>    the base namespace for IPNS seems to be based on the hash of your
>    public key.  This can easily be translated into a DNS name with
>    something like "<peer_id>.ipfs.io"

Is that going to be a special-case that all clients know about?
Otherwise what happens if the owners of iofs.io or the *.io DNS
registrar decide to serve something at https://<peer-id>.ipfs.io?

We'd want to work with the IPNS guys on that.  They already have http://gateway.ipfs.io/ipfs/<peer-id>.  Getting them to reserve the namespace (even if nothing is hosted there) would hopefully be an easy conversation.

 

> An alternative would be to use a URN here for naming and allow different
> schemes.
>
>    - urn:oci:ipfs:...
>    - urn:oci:docker:...
>    - urn:oci:deb:...
>    - urn:oci:dns:foo.example.com:...
>
> Discovery methods and ease of use might be different depending on
> each of these.

This puts everyone on a more even footing (and avoids the DNS-or-not
confusion about something like <peer-id>.ipfs.io.  But putting it
inside the bundle means you'd still need a new bundle if you wanted to
change a metadata location, and there would be no way to offer several
parallel locations [1,2].

I think that this conflates naming with discovery.  Taking a DNS based name and turning that into HTTP call is only a hint.  There is no requirement that there actually be anything hosted there.  You could take this name and use well known directory services to find the bits.  Or ask your DHT peers if they have the bits.  Or rsync the bits around.  Or query DNS via an NAPTR/ENUM type mechanism.

We could allow for hints for locations in the metadata but make those not be part of the cryptographic hash.  Or have a separate set of "unverified metadata" for things like that.

This assumes that there is a verification mechanism.  That is a separate discussion.  But, if we want to enable lots of cacheablility and decentralized distribution we'll need hard verification that is completely divorced from the distribution path regardless.

Joe

 

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/r_x7cmwVFgAJ
     Message-ID: <20150831174...@odin.tremily.us>
[2]: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4#commitcomment-12981584

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[W. Trevor King]

On Mon, Aug 31, 2015 at 11:32:43AM -0700, crai...@google.com wrote:
> I think it is really important that these topics are addressed in OCI, and
> not in CNCF fwiw. It is important that the OCI forum covers

> standardization of image and runtime environment…

I don't see how naming, discovery, or distribution have any impact on
the runtime environment, and I don't see why they need to impact the
bundle specification. For example, my IPFS example earlier in this
thread did all of that without needing spec changes. Can you give
more detail about what sort of impact you see them causing?

Cheers,
Trevor

[W. Trevor King]

On Mon, Aug 31, 2015 at 11:33:44AM -0700, Joe Beda wrote:

> On Mon, Aug 31, 2015 at 11:20 AM, W. Trevor King wrote:
> > On Mon, Aug 31, 2015 at 11:06:52AM -0700, Joe Beda wrote:
> > > An alternative would be to use a URN here for naming and allow
> > > different schemes.
> > >
> > > - urn:oci:ipfs:...
> > > - urn:oci:docker:...
> > > - urn:oci:deb:...
> > > - urn:oci:dns:foo.example.com:...
> > >
> > > Discovery methods and ease of use might be different depending
> > > on each of these.
> >
> > This puts everyone on a more even footing (and avoids the
> > DNS-or-not confusion about something like <peer-id>.ipfs.io. But
> > putting it inside the bundle means you'd still need a new bundle
> > if you wanted to change a metadata location, and there would be no
> > way to offer several parallel locations [1,2].
>
> I think that this conflates naming with discovery. Taking a DNS
> based name and turning that into HTTP call is only a hint. There is
> no requirement that there actually be anything hosted there.

So why require a name at all? I'm fine if folks want to add
bundle-side hints to where you can find something about that bundle.
But I see no need to require a name at all, and no need to require
that that name contains a DNS-like component (the floated commit
currently does both [1]).

> We could allow for hints for locations in the metadata but make those not
> be part of the cryptographic hash. Or have a separate set of "unverified
> metadata" for things like that.

IPFS does not allow any part of the bundle to be unhashed (and I think
partially-hashed stuff is crazy in general. It's certainly annoying
when you're working with OpenPGP packets). I'd put all this
unverified metadata outside the bundle (e.g. in name.json that I'm
pushing to any discovery services [1]).

Cheers,
Trevor

[1]: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4

[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/h_sYNGFiFQAJ
Message-ID: <20150829110...@odin.tremily.us>

[Joe Beda]

Names imply semantic meaning.  They are a usability affordance.  We have file names and not just inodes. We have DNS instead of just IPs.  They are also a way to refer to things that are *not* tied to the location.

Personally, I'd be okay with the name being optional, but that is worth discussing.

As for IPFS -- I'm not an expert here but there is no requirement that the name be based on the hash of the thing being named.  The name being proposed here *isn't* content addressable.  Unless I'm reading it wrong, the current bundle spec only covers what is *inside* of the bundle directory not the name of the directory itself.  How to set up (and share over something like IPFS) a directory of bundles is unspecified.

But this is really all in the weeds, to some degree.

Joe

[W. Trevor King]

On Mon, Aug 31, 2015 at 12:20:41PM -0700, Joe Beda wrote:
> As for IPFS -- I'm not an expert here but there is no requirement
> that the name be based on the hash of the thing being named. The
> name being proposed here *isn't* content addressable.

No, I was saying that if we're using the name as some sort of
in-bundle, metadata-lookup hint, there's no way to adjust that hint
without changing the bundle hash in IPFS distribution [1].

You can put an immutible name inside the bundle, have an immutable
IPFS path for the bundle, and distribute any mutable, metadata-lookup
hints outside the bundle, but that's not what [2] is suggesting.

> Unless I'm reading it wrong, the current bundle spec only covers
> what is *inside* of the bundle directory not the name of the
> directory itself. How to set up (and share over something like
> IPFS) a directory of bundles is unspecified.

Exactly. I don't see much point to an in-bundle name, since the
runtime can launch containers and applications from the bundle without
a name. If the metadata-lookup hint is outside the bundle, can't you
just put the name outside the bundle too? Or if you know the name at
download time, can't you just put the downloaded bundle in
/var/oci/bundles/{name}? What do you gain by having a name-only field
(separate from a metadata-lookup hint) inside the bundle [3]?

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/y6s8roUYFgAJ
Message-ID: <20150831184...@odin.tremily.us>
[2]: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4
[3]: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4#commitcomment-12981893

[Solomon Hykes]

Trevor, I am with you on this one, that is exactly how we plan to integrate RunC and implement OCI compliance in Docker. It's allows a nicely layered design, and a clean separation of concerns between portable runnable format (the scope of this specification) and naming and distribution (out of scope).  Forcing us to store the bundle name inside the bundle breaks that clean separation, and makes implementation really awkward.

[Michael Crosby]

So taking a step back to look at the initial discussion and proposals, this post was initially started to discuss having a way to identify a bundle?  Am I correct on this? 

Brandon proposed adding a Name field to the spec that would contain an URL like string prefixed with a fully-qualified domain name.  

Is this what we are still discussing because I cannot make sense of everything going on in this email thread?

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

--

Michael Crosby

@crosbymichael

[Joe Beda]

I really appreciate the discussion here and I think I see things a lot clearer.  I agree that it is worth taking a step back and reviewing.

To bring it back to what Deepak said: "A developer wanting to distribute an open container image for their application can build once, cryptographically sign once, and host in a human discoverable location a container image that can execute under any OCI runtime."  I understand Solomon's reluctance to commit to something as high level as this but I think it is a useful direction to explore.  Perhaps folks will be more comfortable as the specifics come into focus.

My understanding is that the proposal for putting a name in the bundle is a way to start making these bundles be a distributable thing.  However, it is clear that some folks (Solomon, Trevor) see the bundle as a strict runtime footprint of the container rather than something that can be used for distribution.  I suspect that the term "bundle" is a bit confusing here.  To me it denotes something that can easily be named/discovered/copied/moved.  Perhaps "runtime footprint" instead?

I agree with the layering that Solomon proposes.  To that end, I think it makes sense to do the following:

• Start a specification for the "image format" that is separate from the "runtime footprint".  Call this the OCI image.
• Make these be strictly layered so that the image format is used to construct the runtime footprint but isn't involved after that.  Other mechanisms can be used to create the footprint.  These would, however, be built to work well together.  "Batteries included" and all that.
• Resurrect the discussion of file set layering and composition and put that into this world.  Much of what is logically in the domain of the docker storage/graph driver would go here.
• Start a reference implementation project of the image format creating and manipulation tools.  Perhaps call that "buildc"?

Hopefully if we restrict the idea of a "name" to the buildc layer it will help move things forward.

Joe

[W. Trevor King]

On Mon, Aug 31, 2015 at 03:51:54PM -0700, Joe Beda wrote:
> My understanding is that the proposal for putting a name in the
> bundle is a way to start making these bundles be a distributable
> thing. However, it is clear that some folks (Solomon, Trevor) see
> the bundle as a strict runtime footprint of the container rather
> than something that can be used for distribution. I suspect that

> *the term "bundle" is a bit confusing here*. To me it denotes

> something that can easily be named/discovered/copied/moved. Perhaps
> "runtime footprint" instead?

The directory layout in the current spec is both distributable (see
[1] or just tar it up) and runnable, so I don't see a clear line here,
except for “named/discovered” (which there are no provisions for in
the current spec, but should be able to be cleanly layered over the
current spec).

> I agree with the layering that Solomon proposes. To that end, I
> think it makes sense to do the following:
>

> - Start a *specification for the "image format"* that is separate

> from the "runtime footprint". Call this the OCI image.

I don't see the need to build a separate image format just for naming
and discoverability. For example, my bundle-external, signed
name.json [1] handles naming in a verifiable manner, and after that
discovery is just dropping those names into a search engine so folks
can query for “bundles named like …”, get a set of matching name tags,
verify the signature by someone they trust, fetch the
content-addressed bundle, and run it. If that name.json counts as
your “image format”, then I guess we're on the same page, but I'd
probably call it a “name tag” ;).

> - Resurrect the discussion of *file set layering and composition*

> and put that into this world. Much of what is logically in the
> domain of the docker storage/graph driver would go here.

Please no ;). See [2] and the rest of specs#57.

> - Start a reference implementation project of the *image format
> creating and manipulation tools*. Perhaps call that "buildc"?

Signing a name-tag is pretty simple with existing tools [1]. Folks
interested in building a distribution system on top of OCS bundles
should just have to agree on:

1. A hashing scheme for content-addressing bundles (where I used IPFS
[1]).
2. A name-tag format (where I used a name.json and OpenPGP [1]).
3. A well known registry for publishing name tags (or a set of such
registries, possibly not all being well known).
4. A system for distributing the content-addressed bundles (where I
used IPFS [1]) referenced from those name tags.

If you want a separate tool for building bundles from scratch, I'd
suggest making that a stand-alone tool completely divorced from naming
and distribution.

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/h_sYNGFiFQAJ
Message-ID: <20150829110...@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/issues/57#issuecomment-123832755

[Vincent Batts]

So these examples are only part of it. The point is that even RPM/DEB
repos have not the enforcement of federated namespaces.
Example: you add a third party repo, then accept an update to `bash`
from something besides the core publisher of that content.
This is a feature to many, but a place where running something in
strict vs permissive mode would be the federated namespace win.
Then mirroring, bittorrent, ipfs would lean on deriving the identity
of the publisher, validating the content you have access to.

Again, i'm not proposing creating a new-discovery mechanism, but
having the plumbing that tooling can use to their own discover and
distribution.

[Tim Hockin]

I have been a bit removed from the spec writing - where can I read the
current state of the art on "name tags" or "standardized attachment"?
I don't find that in the spec as it is...

[DL duglin]

Trying to return to the original question... do we need a name field in config.json, I’ll ask here what I asked on Brandon’s branch:

can you elaborate on how and when this "name" field would be used?
For example, if I already have the config.json downloaded would the runtime code ever need to use this URL at all?
If I'm downloading the config.json then I clearly got the URL via some other mechanism since I can't get to 'name' w/o first downloading it.
If this is just a way to say "where this config.json/image came from", then if I copy an image from someone else am I expected to crack it open and modify this field (so it points to my copy) prior to using it?

I'm not against a 'name' field, but we need a clearer definition of its purpose in life.

w.r.t using URLs for a discovery mechanism, I totally agree with using a URL scheme but my gut is telling me that the URL needs to live outside of the image since you can't look inside it until you downloaded it.

-Doug

[Brandon Philips]

On Tue, Sep 1, 2015 at 9:01 AM DL duglin <dug...@gmail.com> wrote:

Trying to return to the original question... do we need a name field in config.json, I’ll ask here what I asked on Brandon’s branch:

Context: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4

After the discussion here I don't think we need a name field in the config.json exactly as I did it in that patch. Although, I still argue that having a single canonical name is a very pragmatic choice and reflects reality to a large degree as there is generally a clear named owner of things.

But, from working through this thread I think there is some concern that we need some flexibility in the namespace options. So, with that consideration we can move towards having a layered approach:

Layer 1 - runnable contents

0) Define a rootfs+config that is "ready to run" (mostly done in the spec)

1) Define a cryptographic digest identity for a bundle (not started)

2) Define an archive format that can confirm the cryptographic digest. We have to generate a string of bytes to generate the cryptographic identity anyways. (not started)

Layer 2 - naming

0) Define a method of giving M human significant names to the N possible namespaces that the bundle may be discoverable in.

1) Define suggested methods for taking a human significant name and finding the runnable contents. For the URL-like suggestion in my patch Joe summed it up well: "there is no requirement that there actually be anything hosted there.  You could take this name and use well known directory services to find the bits.  Or ask your DHT peers if they have the bits.  Or rsync the bits around.  Or query DNS via an NAPTR/ENUM type mechanism."

And after writing this out I think I am just restating what Joe said: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/sY8qPN4lFgAJ

Does this make sense?

Thank You,

Brandon

[Solomon Hykes]

Brandon, your definition of the layers makes sense. Here is my conclusion from this thread.

Layer 1 - runnable contents. Not much innovation going on, huge benefits from standardizing. Clearly within scope of OCI.

Layer 2 - naming. Lots of innovation going on, no clear benefit from standardizing. No clear consensus that it is within the scope of OCI.

The OCI charter explicitly rejects standardizing areas of strong innovation and differences of opinions. A core value of this group is that standards shouldn't be used as weapons to enshrine your design at the expense of your competitor's. I worry that, with your suggested "layer 2", we are seeing the beginning of that.

In summary: please consider creating a separate group to standardize the naming layer, for those who are interested. Personally I believe it is much more valuable and will see very little real world adoption.

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

[Solomon Hykes]

* much more valuable to continue innovating.

[W. Trevor King]

On Tue, Sep 01, 2015 at 10:56:03AM -0400, Vincent Batts wrote:
> Then mirroring, bittorrent, ipfs would lean on deriving the identity
> of the publisher, validating the content you have access to.
>
> Again, i'm not proposing creating a new-discovery mechanism, but
> having the plumbing that tooling can use to their own discover and
> distribution.

Maybe I'm just not understanding what you're proposing. Could you
unpack “deriving the identity of the publisher” and your suggested
plumbing into a more concrete example?

On Tue, Sep 01, 2015 at 08:44:55AM -0700, Tim Hockin wrote:
> I have been a bit removed from the spec writing - where can I read
> the current state of the art on "name tags" or "standardized
> attachment"? I don't find that in the spec as it is...

I'm not sure what you mean by “standardized attachment”; can you
provide more detail?

Name tags aren't in the spec, because there's no reason for the
*runtime* (e.g. runC) to know about them, and I'm not suggesting they
go in the bundle anyway [1]. I'm suggesting name-tags as an option
for a higher-level spec that covers naming and discovery, explaining
the content of a name tag, the API for pushing it to a registry,
querying the registry, and the procedures for verifying a tag and
downloading the referenced bundle. But none of that should go into
opencontainers/specs, since the runtime doesn't care about it, and we
can have many such parallel naming and discovery systems for sharing
the same OCS bundles.

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/h_sYNGFiFQAJ
Message-ID: <20150829110...@odin.tremily.us>

[W. Trevor King]

On Tue, Sep 01, 2015 at 04:42:48PM +0000, Brandon Philips wrote:
> 1) Define a cryptographic digest identity for a bundle (not started)
> 2) Define an archive format that can confirm the cryptographic
> digest. We have to generate a string of bytes to generate the
> cryptographic identity anyways. (not started)

I also think that this is out-of-scope for the “runnable content”
layer (e.g. I'm using IPFS for both of these, but don't expect
everyone else to do so). I'd recommend:

Layer 1 - runnable content

* Define a config that is "ready to run" (mostly done in
opencontainers/specs. This may or may not be distributed in a
directory alongside a rootfs [1].

Layer 2 - cryptographic, content addressable bundle storage

* Define a hashing mechanism and serialization mechanism that can
package bundle directories and identify them with a
cryptographically secure hash.
* Provide some way to use that hash to *also* verify the integrity of
the unpacked-to-disk bundle directory.

I use IPFS for both of these [2], but others should feel free to
invent their own schemes, so long as they don't try and put them in
opencontainers/specs.

Layer 3 - naming and discovery

* Provide some way to apply names to bundle hashes (using the hashes
from Layer 2) in a way that users can verify the assertion

I used name.json and GnuPG for this [2], but others should feel free
to invent their own schemes, so long as they don't try and put them in
opencontainers/specs.

Layer 4 - distribution

* Provide someway to share bundles based on their hashes (using the
hashes from Layer 2).

I used IPFS for this [2], but others should feel free
to invent their own schemes, so long as they don't try and put them in
opencontainers/specs.

So I think we can close out this thread, and interested parties can
spin up new groups for addressing any layers that seem interesting to
them

Cheers,
Trevor

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/6ZKMNWujDhU
Message-ID: <20150826195...@odin.tremily.us>

[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/h_sYNGFiFQAJ
Message-ID: <20150829110...@odin.tremily.us>

[Mark Johnson]

> So I think we can close out this thread, and interested parties can
> spin up new groups for addressing any layers that seem interesting to
> them

+1


MRJ
Oracle

[Vincent Batts]

Right. This thread has clearly meant a lot of different things to a
lot of different people.

I am not saying there must be a "name" field. And while I think a DNS
approach has clear benefits, I am not saying this is something the OCI
is going to setting the standard on, without adoption.
The thing is, I'm agreement that the naming is actively being
innovated on, but also the idea that tracing publisher identity to
published artifacts/bundles _will_ be the point of innovation around
layer 2.

Apart from the values outlined in the charter, it seems reasonable to
have verbiage albeit vague, around "having fully-qualified publisher
identity of content", and "the means to do cryptographic
verification".
That is it.

There will be aspects of the runtime spec that can have deterministic
validation of runtimes like runc and OCI config files. But values like
these above, vague statements would be like qualitative checkboxes.
And it applies to what is actually being innovated on right now. And
is what people are expecting to have standards on.

[W. Trevor King]

On Tue, Sep 01, 2015 at 04:18:15PM -0400, Vincent Batts wrote:
> Apart from the values outlined in the charter, it seems reasonable
> to have verbiage albeit vague, around "having fully-qualified
> publisher identity of content", and "the means to do cryptographic
> verification". That is it.

If you feel like informational notes to that effect would help clarify
things for folks writing naming/discovery/distribution specs, then
probably just PR them? I have trouble seeing anyone objecting to:

For those of you writing naming/discovery/distribution specs,
OCS-bundle users are likely interested in:

* Discovering bundles that address an issue their having (e.g. “show
me all known Nginx bundles so I can spin up a local
reverse-proxy”).

* Verifying that the bundles returned by that search were named by
someone they trust (e.g. “ah, my good friend Alice asserts that
bundle 123 is ‘Nginx v1.9’”).

* …

I'd guess folks designing a new naming/discovery/distribution system
would already know these things, but I don't mind spelling it out for
them in a spec-side note.

What I'd *rather* do, is have a set of references for higher-level
specs, and just point to the things folks had already built:

Related projects:

* [IPOCS](https://ipfs.io/ocs/): sharing OCS bundles via IPFS.
* …

Cheers,
Trevor

[Vincent Batts]

On Tue, Sep 1, 2015 at 1:03 PM, W. Trevor King <wk...@tremily.us> wrote:
> On Tue, Sep 01, 2015 at 10:56:03AM -0400, Vincent Batts wrote:
>> Then mirroring, bittorrent, ipfs would lean on deriving the identity
>> of the publisher, validating the content you have access to.
>>
>> Again, i'm not proposing creating a new-discovery mechanism, but
>> having the plumbing that tooling can use to their own discover and
>> distribution.
>
> Maybe I'm just not understanding what you're proposing. Could you
> unpack “deriving the identity of the publisher” and your suggested
> plumbing into a more concrete example?

The concrete examples are where we draw from for the primitives
involved and needing to be defined.
It is these examples, that we are not going to reinvent the wheel, but
have verbiage that ensures assurance about the artifacts/bundles they
can run, with a runtime like runc.

If a publisher of an artifact puts his content on any or all of the
examples (docker registry, a tarball on their servers, bittorrent and
IPFS), there are steps that the consumer will go through in deriving
the publisher identity of the content, trusting the publisher,
verifying the content, trusting the content.

The implementation of this on these examples can be notary, gpg, trust
in the ipfs framework, etc. We ought not get involved in the
implementation. Though the qualitative fact that these steps occur
needs to have wording around it.

> On Tue, Sep 01, 2015 at 08:44:55AM -0700, Tim Hockin wrote:
>> I have been a bit removed from the spec writing - where can I read
>> the current state of the art on "name tags" or "standardized
>> attachment"? I don't find that in the spec as it is...
>
> I'm not sure what you mean by “standardized attachment”; can you
> provide more detail?
>
> Name tags aren't in the spec, because there's no reason for the
> *runtime* (e.g. runC) to know about them, and I'm not suggesting they
> go in the bundle anyway [1]. I'm suggesting name-tags as an option
> for a higher-level spec that covers naming and discovery, explaining
> the content of a name tag, the API for pushing it to a registry,
> querying the registry, and the procedures for verifying a tag and
> downloading the referenced bundle. But none of that should go into
> opencontainers/specs, since the runtime doesn't care about it, and we
> can have many such parallel naming and discovery systems for sharing
> the same OCS bundles.

You are conflating runc wholly with opencontainers/specs. Runc is a
runtime. Those these values are still in the scope of specifications.
Otherwise it could be called opencontainers/runtime-specs

[DL duglin]

> Layer 1 - runnable contents
>
> 0) Define a rootfs+config that is "ready to run" (mostly done in the spec)
> 1) Define a cryptographic digest identity for a bundle (not started)

Just to be perfectly clear, by “bundle” I assume you mean the “rootfs+config” from step 0, right?

> 2) Define an archive format that can confirm the cryptographic digest. We have to generate a string of bytes to generate the cryptographic identity anyways. (not started)

I’m interpreting this as one possible solution is: define it as a tar ball that must contain the “bundle” in some fashion (e.g. either directly or indirectly), and some metadata (e.g. the cryptographic digest identity). Right?

> Layer 2 - naming
>
> 0) Define a method of giving M human significant names to the N possible namespaces that the bundle may be discoverable in.

Can you elaborate more on why naming is so critical? I’m not necessarily pushing back, I just feel like I’m missing some pieces of the puzzle. To me, I’m equating the result of Layer 1 to be like an MSWord file that I might download from the internet. The tar ball is the file. In the tar ball is some metadata and the actual contents of the rootfs. Likewise, in the Word doc is some metadata and the contents of the document itself.

In this model, the name of the word doc itself isn’t really important - in fact it could have many different names and places it can be found. Now, in the metadata of the Word docs might be some crypto info so I can verify that no one has modified it and its the word doc I was looking for (assuming i have the crypto identity of the file in question). Similarly, the tar ball would contain the crypto stuff for the same purpose.

Do we need to standardize that the “Ubuntu 14.04 bundle” be given a certain tar ball name? Do we need to standardize that it be found at (or identified by) a particular URL? Or, do we just need to make sure that given a crypto identity we can determine whether a given tar ball is in fact the right one for that identity?

If so, it seems to me that the name itself isn’t really the important part but rather we need:
1 - the discovery of the crypto identity of the bundle I want
2 - the discovery of the location (and possible protocol/mechanism) to retrieve that bundle

Or after all of this rambling is #2 (the location) just another way of saying what you mean by “name”? And if so, then I would agree that we need to standardize on how to discover the name/location, but not necessarily the name itself.

(Note, by “we” I mean in general, whether its here or some other group is a discussion for a different audience).

-Doug

[Tianon Gravi]

On 1 September 2015 at 10:19, W. Trevor King <wk...@tremily.us> wrote:
> Layer 3 - naming and discovery

Re-reading this thread a couple times, I'm not sure I agree with the
tight coupling of "naming" and "discovery", and I really don't think
that's what Vincent was proposing. Names are useful even just for
identifying content. Say I've got an "image" (bundle, whatever you
want to call it), and it's got a config.json to tell me how to run it,
and a rootfs. How do I know that when I start it, what I'm going to
get is a "redis-server" process?

So I'm personally +1 to some kind of (optional) name metadata, even if
only for adding some semantic value to content. I do think it also
makes sense to enforce some kind of reasonable structure on these, and
that URL-like works really well for the Go community, and seems like
it'd work well here too (as shown by the success of Docker using it).
Ownership on something like "example.com" is pretty clearly defined.
For cases where such a scheme doesn't make sense, that's fine (and is
exactly why I'd say the field really needs to be optional).

♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

[Vincent Batts]

On Tue, Sep 1, 2015 at 4:28 PM, W. Trevor King <wk...@tremily.us> wrote:
> On Tue, Sep 01, 2015 at 04:18:15PM -0400, Vincent Batts wrote:
>> Apart from the values outlined in the charter, it seems reasonable
>> to have verbiage albeit vague, around "having fully-qualified
>> publisher identity of content", and "the means to do cryptographic
>> verification". That is it.
>
> If you feel like informational notes to that effect would help clarify
> things for folks writing naming/discovery/distribution specs, then
> probably just PR them? I have trouble seeing anyone objecting to:

That is the point of the mailling-list. Discussion before PR.

> For those of you writing naming/discovery/distribution specs,
> OCS-bundle users are likely interested in:
>
> * Discovering bundles that address an issue their having (e.g. “show
> me all known Nginx bundles so I can spin up a local
> reverse-proxy”).
>
> * Verifying that the bundles returned by that search were named by
> someone they trust (e.g. “ah, my good friend Alice asserts that
> bundle 123 is ‘Nginx v1.9’”).
>
> * …
>
> I'd guess folks designing a new naming/discovery/distribution system
> would already know these things, but I don't mind spelling it out for
> them in a spec-side note.

That level of specification is exactly what Solomon was referring to,
it's currently being innovated on, and for the OCI to set standards
around would interfere. That is why I'm saying the most simple
semantics and notable assertions can have verbiage, but not dictating
this level of "how".

[Jonathan Boulle]

On Tue, Sep 1, 2015 at 1:28 PM, W. Trevor King <wk...@tremily.us> wrote:

What I'd *rather* do, is have a set of references for higher-level
specs, and just point to the things folks had already built:

I am genuinely having a hard time understanding this hard line against defining anything other than the lowest level runtime details in opencontainers/specs (which, according to the OCI charter and verbiage in the repository itself is specifications plural). It seems clear from this thread that there is a strong interest from the community - and, notably, from the only three members of the TDC leadership represented thus far - in standardising at least some aspects of naming/identity/discovery - and that many are interpreting this to be well within the remit of the OCI.

[W. Trevor King]

On Tue, Sep 01, 2015 at 04:56:42PM -0400, Vincent Batts wrote:
> On Tue, Sep 1, 2015 at 4:28 PM, W. Trevor King <wk...@tremily.us> wrote:
> > For those of you writing naming/discovery/distribution specs,
> > OCS-bundle users are likely interested in:
> >
> > * Discovering bundles that address an issue their having
> > (e.g. “show me all known Nginx bundles so I can spin up a
> > local reverse-proxy”).
> >
> > * Verifying that the bundles returned by that search were named
> > by someone they trust (e.g. “ah, my good friend Alice asserts
> > that bundle 123 is ‘Nginx v1.9’”).
> >
> > * …
> >
> > I'd guess folks designing a new naming/discovery/distribution
> > system would already know these things, but I don't mind spelling
> > it out for them in a spec-side note.
>
> That level of specification is exactly what Solomon was referring
> to, it's currently being innovated on, and for the OCI to set
> standards around would interfere. That is why I'm saying the most
> simple semantics and notable assertions can have verbiage, but not
> dictating this level of "how".

I don't see anything about “how” in there ;). If you're thinking
about adding text that is even more generic, I expect I'll be very
likely to +1 it ;). So what text are you suggesting?

[Vincent Batts]

Further the discovery and namespace of docker images is tied up in
notary+registry interaction. This can be fully qualified and
searchable. Names are semantically docker image names and checksum
digests. Working out the details of the publisher's identity traveling
with the artifacts will be a different conversation.
The appc discovery is very approachable, and mimics other known
patterns. Much more expressively tying publisher identity (FQDN) and
having a detached signature. Names include FQDN and their checksums.
IPFS and i'm sure others.

From these, there is the notion of publisher and artifact identity.
The "how" is still settling, but there is a need for the common
verbiage.

[W. Trevor King]

On Tue, Sep 01, 2015 at 01:44:38PM -0700, Tianon Gravi wrote:
> On 1 September 2015 at 10:19, W. Trevor King <wk...@tremily.us> wrote:
> > Layer 3 - naming and discovery
>
> Re-reading this thread a couple times, I'm not sure I agree with the
> tight coupling of "naming" and "discovery", and I really don't think
> that's what Vincent was proposing. Names are useful even just for
> identifying content. Say I've got an "image" (bundle, whatever you
> want to call it), and it's got a config.json to tell me how to run
> it, and a rootfs. How do I know that when I start it, what I'm
> going to get is a "redis-server" process?

Naming is asserting that $NAME applies to $BUNDLE. Discovery is (at
least) going from $NAME (or something like it, like a substring or
regexp, or some platform filter, …) to a set of $NAME ↔ $BUNDLE
assertions. What you're talking about is going from $BUNDLE to $NAME.
If you save any $NAME ↔ $BUNDLE assertions locally you can easily
figure out what other folks have called the bundle you're using. For
example:

$ tree /var/lib/oci/bundles/{hash}
.
|-- bundle
| `-- …
`-- names
|-- {hash1}.json
|-- {hash2}.json
|-- {hash3}.json
`-- {hash4}.json

> So I'm personally +1 to some kind of (optional) name metadata, even
> if only for adding some semantic value to content.

Recording that semantic value makes it harder for others to assert a
different semantic value for the same bundle. But that's not a big
deal, if the only use for that name is “a human will read this and
possibly find it enlightening”. However, it seems likely that it will
grow into something like “redis-server v2.8”, or:

{
"name": "redis-server",
"version": "2.8"
}

and then we have to figure out a generic name structure to include in
a spec that doesn't address distribution or provide any direct
semantics for those fields. I'd rather just stay out of that are
entirely and stay focused on things where we do have a clear runtime
impact to limit our scope.

Cheers,
Trevor

[W. Trevor King]

On Tue, Sep 01, 2015 at 02:03:50PM -0700, Jonathan Boulle wrote:
> On Tue, Sep 1, 2015 at 1:28 PM, W. Trevor King <wk...@tremily.us> wrote:
> > What I'd *rather* do, is have a set of references for higher-level
> > specs, and just point to the things folks had already built:
>
> I am genuinely having a hard time understanding this hard line
> against defining anything other than the lowest level runtime
> details in opencontainers/specs (which, according to the OCI charter
> and verbiage in the repository itself is specifications plural).

I'm very interested in what lands in the runtime spec, since I am
writing bundles to be distributed via IPFS. I'm not interested in
inline naming, because I'm comfortable using local directory names to
identify directory bundles, and I'm comfortable using out-of-bundle
name↔bundle assertions to locate bundles. Adding non-runtime stuff
that I don't need to opencontainers/specs means a lower signal to
noise around that repository, and I'd need to filter out distribution
conversations that didn't apply to me. There seems to be very little
cost in spinning up a separate repository (or repositories) to handle
the naming/discovery/distribution layers, and going that route would
keep the signal/noise ratio high for everybody.