Re: CNI discussion - actions

Chris Aniszczyk

On top of what Doug said, I'd like to remind the TOC on what's in the charter currently around projects (section 9):

9. CNCF Projects

(a) It is expected that member companies, and open source community members will bring project assets to the TOC for discussion and inclusion into the CNCF. All such contributions should meet a set criteria created by the TOC and ratified by the Governing Board. The goal is to have an increasing bazaar of projects related to and that integrate with projects already accepted into the CNCF.
(b) Projects can be associated with the CNCF in the following 3 ways:

i. Included in CNCF, under a neutral home for collaboration

a. All aspects of the project are governed by the CNCF
b. The project is marketed by the CNCF as a CNCF project
c. The project should be a core functional component of the CNCF solution. (e.g. such as Kubernetes, Mesos, etcd, etc.)

ii. Associated with the CNCF via an API or specification

a. Includes components where the CNCF may offer or enable multiple options
b. The project is referred to as a component that the CNCF integrates with, not as a project hosted by the CNCF
c. Integration and compliance are defined by an API or specification
d. Active development on the project or component is ideally done in the upstream community

iii. Used by the CNCF

a. A project or component that is completely licensed under an OSI approved open source license and is well managed and used as a component in the CNCF
b. Project is not actively marketed by the CNCF,
c. Active development on the project or component is ideally done in the upstream community

(c) Existing open source projects should continue to run through their existing technical governance structure to maintain cohesion and velocity. Projects approved by the TOC for inclusion in the CNCF will be ‘lightly’ subject to the Technical Oversight
(d) A standard protocol to achieve committer status shall be established across projects based on an individual’s level and duration of contribution. Maintainer status is achieved through contribution to a given project over time and validation by peer
(e) New open source projects initiated in CNCF shall complete a project proposal template adopted by the TOC and be approved by the TOC for inclusion in CNCF. The TOC members shall be afforded sufficient time to discuss and review new project proposals. New project proposals shall include details of the roles in the project, the governance proposed for the project and identify alignment with CNCF’s role and values.

On Thu, Apr 21, 2016 at 2:14 PM, Doug Davis via cncf-toc <cncf-toc@...> wrote:

re: topic "A" - acceptable CNCF projects

IMO the CNCF should allow a variety of types of projects. Ranging from ones that are pure "code" to ones that are just "specifications". While pure spec projects aren't nearly as interesting to me, I'm not comfortable with the idea what we outright ban them. They do have a place in the bigger picture especially if people want to use CNCF as a place to do harmonization type of work and trying to develop a joint spec is the first step in that process.

I'd prefer if we looked for ways to include more projects (as long as they fit the technical aspects of CNCF's scope), instead of trying to define a high bar for acceptance. We're supposed to be here to help/promote CN technology, in all its forms.

re: CNI

To the CNI issues mentioned yesterday, personally, I don't think it matters that in its README CNI mentioned wanting to be a standard. Its interesting that it has since been removed, but given that CNCF is not a standards producing body that sentence meant nothing to me. In fact, if the authors of a spec that's under the CNCF umbrella wanted to take it to w3c, oasis, ietf, etc... to get that formal standardization, that's their choice and IMO shouldn't impact whether they can remain a CNCF project. To imply that a spec that's been developed under CNCF can not be taken down that path feels pretty limiting and should be out of the CNCF's control. In fact, I would argue that if a CNCF spec was so popular and widely adopted that it became a "real standard" it would actually be a good thing and would show CNCF's value over the traditional paper-only standards process.

Let's evaluate CNI on whether its within the scope of CNCF's CN work, and whether the benefits to both sides makes sense.

-Doug Davis
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

Alexis Richardson via cncf-toc ---04/20/2016 12:03:18 PM---All, Issues I heard today:

From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: cncf-toc@...
Date: 04/20/2016 12:03 PM
Subject: [cncf-toc] CNI discussion - actions
Sent by: cncf-toc-bounces@...


Issues I heard today:

1. would be good to talk about some fundamental assumptions about what we think about standards (which is part of the OCI mandate) - suggest we involve the GB in this.  also: there are related topics - service broker, volumes... E.g.: the TOC needs to decide if a project can be "just a spec", or does it need to be "mainly code that just happens to have a spec".

2. invite some CNI stakeholders, not on TOC, to give us the "project point of view" -- eg metaswitch, redhat?

3. perception, brand and timing are issues; would be good to get some more projects on board that aren't 'glue' or 'interface' type things.


So let's separate the discussion:  

A) type of acceptable work/projects in CNCF 
B) is CNI a good fit.   

We need to resolve A independently of B, and can get going first on A.   But, eg in parallel, I think it would be fair to hear from a CNI lead (or two) who is not on TOC.


cncf-toc mailing list

cncf-toc mailing list

Chris Aniszczyk (@cra) | +1-512-961-6719

Join to automatically receive all group messages.