Re: CNI discussion - actions


alexis richardson
 

Doug

I think the main worry is "ex ante and de jure standards", i.e.:
- created ahead of real adoption & maturation of use cases
- by a legislature with wide authority 

I know that Craig liked to say the TOC was like the supreme court (!) for CNCF, but I think we need to be very humble about our reach.

I am OK with standards emerging "ex post and de re".  After the fact, and as a matter of fact.

That doesn't mean we cannot have interop & glue & documents in the CNCF.  We just need to figure out how to do that.  Carefully.

a




On Thu, Apr 21, 2016 at 8:14 PM, Doug Davis <dug@...> 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.


thanks
-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@...





All,

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.


Summary:

So let's separate the discussion:  

A) type of acceptable work/projects in CNCF 
vs  
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.

alexis

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Join cncf-toc@lists.cncf.io to automatically receive all group messages.