At the OCI F2F (https://docs.google.com/document/d/1rL4wiY6Q7R199wz0PBtbbPVjMo_3v2BpO6c1kItPTLw/edit), we discussed kicking off a distribution specification project, based on the Docker distribution spec: https://twitter.com/chanezon/status/938845534466596864

We will have to go through the official OCI channels, which involves a project proposal to the @opencontainers/tob.

@SteveLasker has suggested it would be great to have standardized icons for container related things, OCI is happy to fund this work, here are some things suggested to iconify:

• Public container registry
• Private container registry
• Image – at rest
• Container - instanced
• SBOM (software bill of materials)
• Source artifact, similar to the gpl requirements to have source alongside the binary
• A policy manager, like OPA
• An orchestrator, like kubernetes

We should be wary about any overlap with the kubernetes stencil set: https://github.com/kubernetes/community/tree/master/icons

A new year means a new election:

• Call for Nominations will open on Monday, November 7th and end on Wed November 30th.
• Call for Votes will open Thu, December 1st and end on Monday, December 12th.
• Vote winner will be announced on Monday, January 23rd (terms start on the 29th).

Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company, which they are then voted upon by existing TDC maintainers. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance

e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.

f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.

g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.

FYI @opencontainers/tob, just a friendly reminder that some 4 spots will open up in the TOB early next year:

• (TOB Chair) Brandon Philips (start date: 1/29/2016 - term: 2 years)
• Michael Crosby (start date: 1/29/2016 - term: 1 year)
• Dr. Diogo Monica (start date: 1/29/2016 - term: 2 years)
• Jason Bouzane (start date: 1/29/2016 - term: 2 years)
• Greg Kroah-Hartman (start date: 1/29/2016 - term: 1 year)
• John Gossman (start date: 1/29/2016 - term: 2 years)
• Pavel Emelyanov (start date: 1/29/2016 - term: 1 year)
• Chris Wright (start date: 1/29/2016 - term: 2 years)
• Vincent Batts (start date: 1/29/2016 - term: 1 year)

@crosbymichael, @gregkh, @xemul and @vbatts spots will open up. They are free to nominate themselves and run again though if they so wish. A simple reminder that nominations will come from the TDC maintainers (everyone in a MAINTAINERS file).

"The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year"

"Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer."

We will also elect a new TOB chair directly afterwards and by Feb 11th.

My proposed schedule is this:

• Dec 19th 2016 (Nominations Open)
• Jan 16th 2017 (Nominations Close)
• Jan 17th 2017 (Voting Opens)
• Jan 27th 2017 (Voting Closes)
• Jan 30th 2017 (Announce Winners)

Let me know if you have any comments.

Hey @opencontainers/tob, I will be opening the call for nominations for the OCI TOB Chair position detailed above. Last year, we only had one volunteer via @crosbymichael

From the charter's §6.e:

Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant.

And from §5.b:

b. The OCI TDC has an established scope of work focused on:

…
viii. Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC. The guidelines shall cover the following:

1. establishing and defining roles and responsibilities (at a minimum, a role for committers or maintainers authorized to commit code to the codebase);
2. defining the process or requirements to take on a role in the TDC (e.g. how to become a contributor, or how to become a maintainer);
3. the process by which participants in the TDC may give up or be revoked of their roles (e.g. how to remove maintainers); the rules for decision making in the TDC; and the process by which participants in the TDC may give up or be revoked of their roles (e.g. how to remove maintainers); the rules for decision making in the TDC; and

As far as I'm aware, the only TDC role that any OCI Project has defined is “maintainer”. So I think non-maintainers are not TDC participants, and are therefore excluded from standing for TOB election.

However, the charter is not clear on a number of points. Perhaps my reading is missing the spirit of the charter and the charter-writers only intended that sentence to lift a potential OCI Member employee restriction. The charter is clear that the current TDC maintainers will be doing the electing of this round, and since those are the same folks who have the power to induct new TDC maintainers/participants, I don't see how restricting the candidates to current TDC participants serves any purpose. And for the OCI Member round of TOB elections, I don't see why OCI Members would want their candidate pool limited to current TDC participants, since they have no direct control over who that set of people is.

The @opencontainers/tob needs to elect a new chair for 2023!

Is anyone from the @opencontainers/tob interested in running?

@samuelkarp would you like to stand again?

Right now, it is forbidden for more than two TOB members to be employed by the same employer:

e. The TOB shall be composed of nine (9) individuals elected for their
expertise, contribution to the advancement of container technologies and are
considered to be thought leaders in the OCI ecosystem. Anyone may be elected
to the TOB, regardless of whether the individual is an employee of an OCI
Member, so long as they are an OCI TDC participant. A TOB member is elected
as an individual and not as a representative of his or her employer. No more
than two (2) TOB members may be employed by the same entity or its
affiliates. Affiliates shall be defined as entities owning 50% or more of an
entity, or owned by or under common ownership with each other. TOB members
may not designate alternative representatives.

However, there is no procedure for dealing with this rule being violated. There are two circumstances where this rule could be violated:

1. Due to a TOB election, there are more than two TOB members who are employed by the same entity (this could be that one TOB member was already an employee of FooBarCo, and two canidates were employees of FooBarCo, and both employees got above the necessary threshold of votes).

2. A TOB member changes employers (either willingly, or due to their employer being bought by another company) which employs two TOB members already.

In my view, these two circumstances should have separate procedures:

(1) should be handled by walking through the ranked list of candidates after the election has been completed, and adding each candidate if they are eligible. If they are not eligible, the next candidate in the ranked list is considered. If there is a tie (even after removing inelligible candidates from that tie), then a fair coin toss could be used.

(2) should be handled by a by-election for a subset of the TOB's seats. It might make the most sense to only have a by-election for the TOB members' whose employer has changed, but another option would be simply to have a by-election for all TOB seats which violate s6(e) to avoid discriminating against TOB members who . In either case, whoever is elected in the seats acts as an interim TOB member, and their term ends at the same time as the previous holder (in other words, the by-election doesn't give the new TOB member a two-year term). This procedure probably should be considered along with #82 to avoid any extra complications.

One of the TOB's pain points in governance is the lack guidance on how to deal with not enough maintainers reviewing changes to individual OCI Projects.

The current charter says the following on oversight of TDCs:
The TOB shall not dictate or interfere with the day-to-day work of individual OCI Projects or their decisions.

This means that the TOB cannot effectively resolve issues in the TDC that stem from inactive maintainers. What is the TOB's role in this regard?

This issue was brought up at an OCI Certification Working Group.

Should it just share the runtime-spec MAINTAINERS or do we select a new set?

We don't need to address this immediately, but it's something we should get clarity on it in the future.

Working Group Proposal: Reference Types

Proposal created from OCI WG template.

Reference Types OCI Working Group - Governance Charter

This document describes the basic governance principles for the Reference Types Working Group (the “WG”).

The WG operates as an OCI Working Group under the Open Container Initiative (OCI) Charter, which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below.

Purpose

As cloud native development continues to grow, there is increased interest in evolving registries to natively store, discover, and pull a graph of content associated with specific container images in a registry. Use cases for said associated artifacts include but are not limited to Software Bill of Materials (SBoM), security scan results, and signing. Having a native way to store and discover artifacts associated with other artifacts enables end-users to answer the question of: “What SBOMs or signatures are associated with this container image?”

Scope

• Define and deliver the capability to store, discover, and pull a graph of artifacts associated with a specific artifacts to OCI distribution compliant registries. These set of capabilities has been commonly known as "reference types" or "references".
  • Define supported use cases
  • Document impact to existing user-facing tools and registries
  • Define the method for creating, distributing, and discovering referenced objects
  • Document user expectations for promoting an artifact between registries with its references
  • Document onboaring process for registies and user-facing tools to adopt reference types
  • Defined expectations for artifact reference lifecycle management
  • Deliver a reference implementation of the reference types proposal

Out of Scope

• Identified out of scope items will be listed here as WG progresses

Intended work product

• Referrers API specification that provides the ability to discover references to existing container images. These include listing signatures, SBoMs, security scan results that refer to the digest of a manifest. The referrers API specification will sit within or along side the Distribution specification.
• Identify, and document the pros and cons for versioning the existing manifests, compared with creating a new manifest to support reference types.

Proposed Owners

• Lachlan Evenson (@lachie83)
• Justin Cormack (@justincormack)
• Michael Brown (@michaelb990)
• Derek McGowan (@dmcgowan)
• Jon Johnson (@jonjohnsonjr)

Sponsors

• Microsoft
• AWS
• Docker

Related issues/PRs

• #96
• opencontainers/artifacts#27
• opencontainers/artifacts#29
• opencontainers/artifacts#37
• opencontainers/image-spec#827
• opencontainers/image-spec#828
• https://github.com/oras-project/artifacts-spec/

Governance

• Working Group:
  • The TOB is establishing the WG as an OCI Working Group, pursuant to section 6(p) of the OCI Charter.
• Owners:
  • The WG proposal to the TOB will specify one or more initial "owners" of the WG.
  • The current owners will be listed in the OCI Working Group documentation.
  • The owners shall be responsible for:
    • scheduling regular meetings of the WG community;
    • facilitating open discussion among WG community participants;
    • coordinating and managing the development of the WG work product and outputs;
    • recording decisions that are reached by the WG community; and
    • keeping the TOB regularly informed about the status of the WG’s efforts, including when the WG has readied the work product and outputs for TOB approval.
• Maintainers:
  • If the WG owners request the TOB to approve a draft specification as a released OCI Specification, the request shall include a list of proposed "maintainers" of the OCI Specification.
  • The current maintainers will be listed in the OCI Working Group documentation.
  • The maintainers shall be responsible for continuing the work of overseeing updates, improvements and changes to a released OCI Specification on an ongoing basis.
• Meetings:
  • Meetings of the WG shall be open to the public.
  • Participants in the meetings shall comply with the OCI Code of Conduct and all other policies of OCI and The Linux Foundation.
• TOB Approval:
  • The WG shall operate pursuant to the procedures set forth in section 6(p) of the OCI Charter, with regards to obtaining TOB approval for initial release of the work product and outputs as an OCI Specification or other OCI Project, and for subsequent maintenance activities thereafter.
• Amendments:
  • The owners of the WG may from time to time propose to the TOB (1) amendments to this WG Governance Document, and/or (2) changes to the composition of the owners or maintainers of the WG.
  • As set forth in the OCI Charter, the TOB may, in its discretion by a two-thirds vote, approve or reject the requested amendments or changes.
  • As set forth in the OCI Charter, the TOB may also disband the WG by a two-thirds vote.

Okay, so the OCI Charter currently states that votes must pass with a super-majority (two-thirds). However, it seems that some sections conflict on the question of exactly how two-thirds are counted and I'd like to clarify whether these different voting rules are intentional:

Section 6 (n) states that all votes are passed with two-thirds of votes cast (this sentence is also phrased very strangely, mentioning the Trademark Board in the middle -- in fact I believe this is a copy-paste error from Section 4 (d) which uses very similar wording.) I also hasten to mention that it looks like voting on GitHub isn't actually okay according to the Charter but 🤷.

The intention is for the TOB to operate by consensus. However, if consensus cannot be achieved, the Trademark Board shall vote on a decision. All TOB Votes, either at TOB meetings, via email or electronic voting service, shall pass with a two-thirds vote of votes cast, on a one (1) vote per TOB member basis. An abstain vote equals not voting at all. [emphasis added]

However, Section 2 (c) appears to say that project approvals require a two-third vote of the entire TOB (so not voting counts as a vote against the motion). Maybe it's okay that this is a different rule, but this is one of the most important roles of the TOB and it's a bit odd that in a later section the rule appears to be contradicted by an unqualified "all".

Any Member can bring forward a new project proposal to the TOB for review. Approval of new OCI Projects requires a two-thirds vote of the TOB. [emphasis added]

And then Section 6 (h) also appears to say that changing the system of voting requires a two-third vote of the entire TOB (so not voting counts as a vote against the motion):

Initial elections of TOB members shall be run using the Condorcet-IRV method through the Cornell online service (http://civs.cs.cornell.edu/). The TOB may change the methodology or service used in future elections via a two-thirds approval vote of the then-serving TOB. [emphasis added]

And again in Section 6 (j)(ii) for calling meetings:

[The TOB shall meet on an as-needed basis, in a timely manner after issues are directed to the TOB from:] as the TOB determines via vote of at least two-thirds of the TOB members [empahsis added]

And yet again in Section 12 (a) for amending the Charter:

This Charter may be amended by a two thirds vote of the Technical Oversight Board, subject to veto by The Linux Foundation Board of Directors for reasonable cause, with thirty (30) days’ notice to the OCI Members before taking effect. [emphasis added]

So it seems like Section 6 (n) is simply an incorrect copy-paste of the Trademark Board's rules (there are literally no more references to TOB votes in the Charter other than the exceptions to Section 6 (n) I've listed). And from memory, we've always run votes as though Section 6 (n) didn't exist. So should we just remove it (as part of the cleanup I'm working on)?

This question is quite important when it comes to non-meeting votes (where we do not technically have to establish a quorum) because in such cases a two-thirds vote could be less than two-thirds of TOB members -- which seems like a bad idea.

See this thread:
https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/1pgiEffnu0M

We should list previous OCI TOB folks and thank them for their service!

The OCI Release Process should differentiate between major and minor releases.

Possibly longer waiting period and higher threshold for consensus for major (vs. minor)

/cc @philips

A start was made on thinking about how various repos within the OCI currently fit into a set of project types (specs, reference implementations, helper libraries). We need to finish this effort and publish it to provide guidance to both the TOB (for voting on new proposals) as well as future potential submissions to make is less vague on what fits in the OCI scope.

A start on this effort is located in the TOB call notes: https://hackmd.io/kKl1ECKnSLWhgk7dZ2WUFQ#Categorizing-Project-Types

Even if we have people willing to take on the role of maintainership, PRs to add these people are not even being reviewed. For example:

• opencontainers/image-spec#911
• opencontainers/image-spec#909

I propose that a supermajority 2/3 vote from TOB members can add or remove a maintainer from any subproject in order to keep OCI alive and well.

We need to elect an OCI TOB Chair starting next week

The seat is currently held by @estesp :)

We will have nominations open until Feb 3rd EOD PT time for the TOB

A new year means a new election:

• Call for Nominations will open on Tue, January 8th and end on Friday January 18th.
• Call for Votes will open Monday, January 21st and end on Friday, January 26th.
• Vote winner will be announced on Tuesday, January 29th.

FYI: @opencontainers/tob

@amye and I will work in tandem with the @opencontainers/tob to audit the current list of maintainers.

We will make recommendations based on the data we present to the TOB :)

• image-spec: opencontainers/image-spec#834
• runtime-spec: opencontainers/runtime-spec#1101
• distribution-spec: opencontainers/distribution-spec#262
• runc: opencontainers/runc#2891

Now that the TOB Elections for 2017 are over, it's time to elect a new TOB chair:
#20

N1-0 (@android:color/system_neutral1_android#

There's been a discussion in the OCI TDC about potentially moving the selinux library out of runc and into a new project (say something like opencontainers/libselinux)

I'm creating this issue as a placeholder while the OCI TDC finishes debating whether to move forward or not. If we move forward, we will consult the TOB and begin a formal project proposal.

cc: @mrunalp

Much of the current release process draft focuses on maintainers, it may be worthwhile to add some specificity on how non-maintainers provide feedback.

/cc @philips

We need to elect an OCI TOB Chair.

The seat is currently hold by @crosbymichael.

Now that the OCI TOB is established for 2018, we need to elect a new chair.

Right now if the TDC Maintainers feel that the TOB is not fulfilling their duty correctly, they have no recourse other than to go to the Linux Foundation (and I'm not sure how that process would even work). Should we have a "no confidence motion" concept in the Charter (such as a qualified super-majority of TDC Maintainers can trigger the TOB be dissolved and a special election for all seats)? Then again, we've never had any tensions between the TOB and TDC Maintainers so maybe this is purely a theoretical thing which isn't worth extra text in the Charter? But then again, if we ever need it then it'd be too late to ask the TOB to add it.

I am writing this as a separate issue, because it won't be included in my first round of charter refactoring but it is something that I wanted to open a discussion about.

On Monday, October 12, 2020, representatives from Azure, AWS, Google, IBM, Docker, and GitHub met to discuss how, as an industry, we believe we can address the problem. We need a short term solution for the pending November 1st changes that enable stability through the holiday lockdowns, with a longer-term plan that helps customers adapt their workflows.

To avoid customer confusion, and finger-pointing, the cloud vendors and docker have agreed to co-author a paper providing guidance to customers for how they can adapt their workflows in incremental steps. The goal is to provide stability to an ecosystem, with an opportunity to innovate in a common direction. The Open Container Initiative (OCI) was intended to provide a vendor-neutral body of governance. We would like to publish the paper under the OCI umbrella in the coming weeks.

The content will be something like:

• Public content is great to consume, but consider the risks when sourcing public content in mainline/production workflows.
• Consuming public content imposes production risks as it assumes all connections between the production host and the public source are fully available. It assumes the content is in a secure and reliable state, compared to the previously tested version. And, it assumes someone is bearing the costs to host that continually pulled, large content.
• As a best practice, import public content to a private registry, do some amount of incremental testing and utilize from your private registry
• This includes, not building FROM docker hub, rather build FROM your private registry the content you’ve imported and verified
• Automate the importing and verification, to assure you have the latest, but test the latest to assure it's safe and reliable for your environment
• As you adapt your import/verify/promote workflows, docker hub users can provide authentication to avoid throttle limits

The draft doc is located here: Consuming Public Content

We hope to complete the paper by 11/23, giving time for review and posting prior to Nov 1s.
Each cloud vendor can then point their cloud specific docs on how to implement a buggered workflow, enabling local reliability and performance, without the risks of accessing public content in critical workflows.
The paper will also direct customers to use Docker Authentication for pulls from Docker Hub, providing identity within multi-tenant cloud services.

This is the tracking issue for the onboarding administrative tasks for the Reference types working group:

Related issues/PRs

• #96
• #103

cc @justincormack @dmcgowan @jonjohnsonjr @michaelb990

• Merge proposal PR - #103
• Request TOB creation of a new repo (suggest wg-reference-types) under the OCI GH org with proposed owners in the proposal to have approve and merge access
• Create WG README (similar to this) in the new repo
• Create slack channel wg-reference-types in OCI slack
• Create mailing list
• Assign TOB liaison (optional)
• Send out Doodle to schedule WG meeting
• Setup Zoom schedule and provide access to proposed owners

Per discussion with the @opencontainers/tob members in March/April 2020, there are aspects to the OCI governance which are significantly out of date or simply related to the early construct under which the OCI was formed in 2016.

After the move of opencontainers.org to GitHub (see the work underway in https://github.com/opencontainers/opencontainers.org) we should be able to do this with a standard GitHub pull request/approve/merge workflow.

Part of this work needs to specifically deal with the question of TDC vs. TOB vs. maintainers of OCI projects:

• related: #2
• related: OCI TOB discussion: https://hackmd.io/kKl1ECKnSLWhgk7dZ2WUFQ#Notes (see item 2 TODO)

All of the references to "Executive Director" in the Charter are written as "Linux Foundation Executive Director" or "Executive Director of the Linux Foundation" (who is Jim Zemlin). @caniszczyk is the Executive Director of the OCI, but it seems like the Charter seems to imply that he has no procedural powers because there are no references to his position? In fact as far as I can tell, it doesn't even establish his existence.

Is this a mistake -- should all of the references to "Executive Director of the Linux Foundation" or "Linux Foundation Executive Director" actually be "OCI Executive Director"?

A new year means a new election:

• Call for Nominations will open on Monday, November 2nd and end on Friday November 23rd.
• Call for Votes will open Tuesday, December 1st and end on Thursday, December 10th.
• Vote winner will be announced on Monday, January 25th (terms start on the 29th).

Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company, which they are then voted upon by existing TDC maintainers. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance

e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.

f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.

g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.

#104

Red Has announced an agreement to acquire CoreOS:
https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership

The @opencontainers/tob has certain rules in place to ensure only a certain number of representatives can be from one entity:

e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.

I will reach out to Red Hat to see which two candidates they desire to keep on the TOB. After that is done, I will run another election for the newly available TOB slot.

My proposed timeline:

• Nomination Period: Jan 31st - Feb 6th (end of day PT)
• Elections: Feb 7th - Feb 12th (end of day PT)
• Results: Feb 13th

Per many discussions, and most recently in the @opencontainers/tob call, the scope table is clearly out of date and not applicable to the current state of the OCI.

Options are drop it with the governance update work in #72, or rewrite it/replace it with a prose version that flows from a clear expression of why the OCI exists followed by a list of projects and their reasons for existing in the OCI universe of projects. Feedback is that there is no clear, understandable place to understand these core ideas and to differentiate newcomer's understanding of OCI vs. CNCF, as one example.

Related: #10 (would potentially be superseded by a rewrite as a non-table and would not require any special rules to update)

We currently do not have a process for OCI Project removal and archival. It's unclear whether these should even be considered two separate processes. The TOB does have the right to remove projects under Section 2 (b) of the Charter, but it seems like this is something which should be slightly more formalised (such as requiring a 30 day notice with a comment period before archival of the project -- and likely we would never want to outright remove a project from the OCI).

Are there any strong opinions about what the process should be? In keeping with the apparent consensus on the TOB calls, we should probably make this as minimal as possible.

I am writing this as a separate issue, because it won't be included in my first round of charter refactoring but it is something that I wanted to open a discussion about.

Summary

Adopt the ORAS project located at deislabs/oras.

Overview

ORAS is a CLI that can publish arbitrary content to an OCI registry, with special features for setting mediatypes on manifest configs and on content.

Note: the manifest mediatype itself is always application/vnd.oci.image.manifest.v1+json.

Example - uploading rockets, a brand new type of package:

# Create a thing
printf '🚀' > rocket.txt

# Create a manifest config
printf '{"RocketVersion":"v0.1.0"}' > rocket-config.json

# Upload your thing with a custom mediatype
oras push localhost:5000/mystuff/myrocket:v0.1.0 rocket.txt:text/plain \
  --manifest-config rocket-config.json:application/vnd.acme.rocket.config.v1+json

See manifest created:

$ curl -s -H 'Accept: application/vnd.oci.image.manifest.v1+json' \
    http://localhost:5000/v2/mystuff/myrocket/manifests/v0.1.0 | jq
{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.acme.rocket.config.v1+json",
    "digest": "sha256:310175f34d2d4d5cba3418be06ddd1ef948147d729516d78318ec7f5c2d83d49",
    "size": 26
  },
  "layers": [
    {
      "mediaType": "text/plain",
      "digest": "sha256:ebbc0b2870eb323f2b6cffa5c493ceef81ae7eb36afc73d4e0367301631daec5",
      "size": 4,
      "annotations": {
        "org.opencontainers.image.title": "rocket.txt"
      }
    }
  ]
}

Get that thing:

$ curl -s http://localhost:5000/v2/mystuff/myrocket/blobs/sha256:ebbc0b2870eb323f2b6cffa5c493ceef81ae7eb36afc73d4e0367301631daec5
🚀

Additional Usage

ORAS is built primarily on top of Go packages provided by containerd, but it also imports packages from the docker/cli, which enables "docker-style" auth login:

oras login -u username -p password localhost:5000 -c rocket-creds.json

There are also public Go packages available to build on top of ORAS. The following is the equivalent of the rocket example with the CLI above, but in Go:

package main

import (
	"context"
	"fmt"

	"github.com/containerd/containerd/remotes/docker"
	"github.com/deislabs/oras/pkg/content"
	"github.com/deislabs/oras/pkg/oras"
	ocispec "github.com/opencontainers/image-spec/specs-go/v1"
)

func main() {
	ctx := context.Background()
	resolver := docker.NewResolver(docker.ResolverOptions{})
	store := content.NewMemoryStore()

	registryRootURL := "localhost:5000"
	registryNamespace := "mystuff/myrocket"

	rocketVersion := "v0.1.0"
	rocketFileName := "rocket.txt"
	rocketMediaType := "text/plain"
	rocketContent := []byte("🚀")
	rocketDescriptor := store.Add(rocketFileName, rocketMediaType, rocketContent)

	rocketConfigMediaType := "application/vnd.acme.rocket.config.v1+json"
	rocketConfigContent := []byte(fmt.Sprintf("{\"RocketVersion\":\"%s\"}", rocketVersion))
	rocketConfigDescriptor := store.Add("", rocketConfigMediaType, rocketConfigContent)

	ref := fmt.Sprintf("%s/%s:%s", registryRootURL, registryNamespace, rocketVersion)
	_, err := oras.Push(ctx, resolver, ref, store, []ocispec.Descriptor{rocketDescriptor},
		oras.WithConfig(rocketConfigDescriptor))
	if err != nil {
		panic(err)
	}

	fmt.Println("Pushed to", ref)
	fmt.Printf("\nTry:\n\ncurl -s -H 'Accept: application/vnd.oci.image.manifest.v1+json' \\\n" +
		"    %s/v2/%s/manifests/%s | jq\n", registryRootURL, registryNamespace, rocketVersion)
}

You can see all features in the project README.

Adoption

The following projects are already successfully using ORAS to work with custom artifacts:

• Helm
• Conftest
• Singularity

Why move it into opencontainers?

For a few reasons:

• Provide end users a method to publish and retrieve any type of content to/from an OCI registry
• Provide a reference implementation for the in-progress artifacts spec
• Expand awareness of the project to a broader audience
• Encourage more community contributions

I've been thinking a bit about umoci and ORAS proposals (#67 and #68) - how do people feel about some generic new repo like opencontainers/tools which could contain a collection of various tools enabling OCI-related work?

Some initial tools we can include:

• umoci: Modifies Open Container images (https://github.com/openSUSE/umoci)
• ORAS: OCI Registry as Storage (https://github.com/deislabs/oras)
• Reggie: Simple Go HTTP client for OCI Distribution (https://github.com/bloodorangeio/reggie)

This repo can have its own criteria for which tools should be added vs. going through the TOB. This reduces the burden on TOB for "blessing" certain tools, while these tools still benefit from being under the opencontainers namespace.

We could organize it using top-level directories in the repo corresponding to the tool, for example:

|____tools/
| |____oras
| | |____README.md
| | |____<oras_source>
| |____reggie
| | |____README.md
| | |____<reggie_source>
| |____umoci
| | |____README.md
| | |____<umoci_source>

This introduces some challenges around the release process and how maintainers operate, but perhaps it's the best approach all things considered. I'm imagining the repo adopting several other tools people would be willing to contribute. It may also serve as a new home for other repos like go-digest, runtime-tools, and image-tools.

Thoughts? Happy to help organize and maintain a repo like this.

A new year means a new election:

• Call for Nominations will open on Thursday, January 4th and end on Thursday, January 18th.
• Call for Votes will open Friday, January 19th and end on Friday, January 26th.
• Vote winner will be announced on Monday, January 29th.

FYI: @opencontainers/tob

https://www.coreinfrastructure.org/programs/badge-program

How To Add New Capabilities to OCI *

We have a few issues we're all wrestling with, with varied approaches and opinions on how to solve a problem. I'd suggest we each have slightly different priorities and we're focusing on the problems we either think we need or can solve. Unfortunately, we have come to a point where we have some bottlenecks in what extensibility we have.

To help frame a discussion, I'd suggest we need a framework for the discussions:

1. Gather a list of the core issues we collectively believe are relevant.
2. Find the things we can agree upon.
3. Propose some solutions, which map back to the agreed upon list.
4. Capture the pros and cons with each approach. There is no silver bullet here

Categories of changes

We have at least 2 major categories of changes:

1. How to add new capabilities to the container image, including compression formats:
   • Proposal to add Encrypted Layer Mediatype by lumjjb · Pull Request #775
   • Formalize support for zstd compression: v1.1.0 ? · Issue #803
   • Additional usability issues related to building and maintaining multi-arch images.
2. How to add signatures, and other linked artifacts
   • Add a new OCI artifact manifest PR #29
   • Add new descriptor.data field PR #826 and descriptor.reference field PR #828 to image-spec
   • Add new generic object manifest - which could account for #1 as well

Constraints

What are the constraints we're trying to adhere to:

1. Not break existing container runtimes, including down-level clients
2. Not break container registries

"Not break" means we can add behaviors, but do it in a deterministic way.

Elephants in the Room

To confront, head-on, some concerns we're all facing:

1. Is the image-spec frozen?
2. How do we unblock innovation for various projects

Is the image-spec frozen

I don't believe anyone desires the image-spec to be frozen. Rather, the question is: How do we make changes to the image-spec without breaking down-stream clients?

The varied designs around OCI Artifacts, Notary v2, cosign/sigstore, Compression Support all bump into this question, which we haven't actually clarified.

Facts:

• The image-spec has a declared version 1.0, dating back to August 2017.
• Registries (implementations of the distribution-spec) use the schemas within image-spec and image-index to manage content.
• Folks are brainstorming around OCI Image v2. It's unclear how many of these can be implemented if we don't unlock extensibility.
• Registries store more than container images. Although OCI Artifacts was able to work within the current image-spec, there were many constraints that make this awkward.
  • Config is required and used to determine the artifactType
  • At least 1 layer is required
  • Lack support for reference types (in either direction)
• OCI Artifacts was created with the constraint that any schema change to the image-spec would require a version change to the image-spec.
• Although the distribution-spec doesn't explicitly call out garbage collection, delete semantics are specified are defined, and some form of content management is a requirement for any production registry.
• The image-spec and distribution-spec exist to provide consistent user expectations for images and other artifact types as they work with various cloud providers, vendor products and OSS projects that adhere to the specs.
• Any change will take time for adoption and will require work to be useful. Where the work is required is in the details of the various proposals, based around a set of constraints.

What types of changes can be made, and how

The question could then be sub-categorized as:

• What changes to the spec can be done within v1?
  • Annotations, as optional strings appear to meet the bar
• What changes require a version change?

Things We Agree Upon

Are we in agreement to the following?

• Linking artifacts is needed to support signatures, SBoMs and other artifact types to be addeded, without changing the digest and/or tag.
  • There's no specifics on which signature format, nor which SBoM format here. Simply an additional artifact can be added, referencing existing artifacts
• An API for querying the references
  • Whether this is added to the distribution-spec, or an optional extension, the API is considered matched behavior to the ability to link artifacts.

Current Proposals

There are three proposals up for consideration, with pros and cons associated with each. Before we can get into the pros & cons, there's presumptions for how OCI will support extensibility.

1. Add a new OCI artifact manifest
2. Add new descriptor.data field and descriptor.reference field to image-spec
3. Add new generic object manifest

• 1 and 2 are based on whether changes to the image-spec are possible. Conceptually, either proposal can be captured in a new manifest, or merged into the image-spec, with various limitations.
• 1 and 2 do not account for compression formats, or other OCI Image v2 points of extensibility.
• 1 and 2 are focused on linking new types to image-manifest and image-index objects, they don't focus on changing behavior of the existing container image toolchains.
• 3 accounts for references and may account for OCI Image v2 extensibility options.

Decision Criteria

1. As 2 of the proposals are based on how we can make changes to the image-spec, I'd suggest we start with describing what and how we might accept changes to image-spec.
2. Based on the outcome of image-spec changes, we can discuss the 3 options. The 3 options can be adapted to how they apply to the image-spec change process.

Congrats @vbatts

https://kinvolk.io/blog/2021/04/microsoft-acquires-kinvolk/

After speaking with @philips, we will do a proposed update of the OCI Code of Conduct to be more modern with the state of the art in this field. The LF best practice moving forward is having the community be the focal point of the enforcement (usually via a committee of some type). We can decide to just delegate this to the TOB, a subset of the TOB or a newly formed code of conduct committee.

Note, this will be a post v1.0 activity

A new year means a new election:

• Call for Nominations will open on Tue, December 3rd and end on Friday January 10th.
• Call for Votes will open Monday, January 13th and end on Monday, January 20th.
• Vote winner will be announced on Monday, January 27th.

Each OCI member can submit up to one candidate for nomination, which they are then voted upon by OCI membership. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance

e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.

f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.

g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.

opencontainers/image-spec#486 introduces a dependency on a stable upstream implementation of https://github.com/docker/go-digest, which was recently broken out of the https://github.com/docker/distribution project.

This package has been instrumental in providing a strong hash-identity implementation in Go and I hope to extend this to OCI.

Let's support this by moving this into a https://github.com/opencontainers/go-digest project specifically oriented towards providing this functionality throughout the container ecosystem. While this package does support opencontainers/image-spec, it is broadly useful in other image formats or outside image formats.

Having a solid, battle-proven, common digest implementation in OCI for use in and outside the image-spec will ensure long lasting security and interoperability throughout the container ecosystem.

Provisions:

1. https://github.com/docker/go-digest would become https://github.com/opencontainers/go-digest.
2. Maintainers would the current image-spec maintainers.
3. I, @stevvooe, will act as lead maintainer on this project.

@caniszczyk @philips

This is listed under "Tier 1: Replace Immediately" in the Inclusive Naming Initiative:
https://inclusivenaming.org/word-lists/tier-1/#master

There are currently 3 avenues for engaging with the TOB: mailing list ([email protected] I believe), GitHub issues, and meetings.

Is there a preference? My vote is for GitHub issues first, mailing list second, and meetings third.

A new year means a new election:

Call for Nominations will open on Mon, Nov 29 2021 and end on Mon, Jan 10 2022
Call for Votes will open Tue, Jan 11 2022 and end on Tue, January 18 2022.
Vote winner will be announced on Monday, January 24th

Each OCI member can submit up to one candidate for nomination, which they are then voted upon by OCI membership. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance

e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.

f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.

g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.

The 5 TOB slots open are:

• Phil Estes [AWS] (TOB Chair) (term date: 1/29/2020 - 1/29/2022)
• Wei Fu [Alibaba] (term date: 1/29/2020 - 1/29/2022)
• Jon Johnson [Google] (term date: 1/29/2020 - 1/29/2022)
• Samuel Karp [AWS] (term date: 1/29/2020 - 1/29/2022)
• Steve Lasker [Microsoft] (term date: 1/29/2020 - 1/29/2022)

Proposal is to create a separate repository to cover Artifact Distribution.
Accounts for: Artifact registry support #65

The new repository would explain:

• how distribution is used to store additional types.
• guidance to registry owners for how to parse artifact types
• guidance to artifact authors for how manifests and index are used to define new types

With artifacts defined here, the distribution spec can be updated to remove references to images, making it more about storing index and manifest references to layers.

Proposed repository name:
artifact-spec

There's been confusion on how to directly update the scope table:
https://www.opencontainers.org/governance/oci-scope-table

Lets come up with a proposal to clarify the last section:

MECHANISM FOR ADDING “ROWS” TO THIS TABLE

The appropriate mechanism for adding, removing or modifying rows to this table (e.g. creating a proposal for an additional optional layer) is to bring it before the TDC. The TOB can be a source of appeal and/or can discuss if there isn’t a clear consensus in the TDC.