Date   

Re: [VOTE] CNCF SIGs Proposal

Sandeep Shilawat
 

+ 1 

On Mon, Mar 25, 2019 at 5:45 PM "Li, Xiang <x.li@...> wrote:
+1 binding


Re: [VOTE] CNCF SIGs Proposal

Li, Xiang
 

+1 binding


Fluentd Graduation Request (2017-2019)

Eduardo Silva
 

Hello TOC!,

My name is Eduardo Silva from Fluentd project.

On November 2016, sponsored by Brian Grant, Fluentd joined CNCF in the Incubating stage. One year later in November 2017, we submitted PR #69 asking for the project Graduation. Since that time we have been waiting for feedback asking to get started with the voting process. Unfortunately, due to previous TOC overload, our project review has been delayed many times and for months.

As of mid-2018, we started to transition Fluentd trademark (hold by Treasure Data at that moment) to the Linux Foundation, it took a lot of time since the trademark was in several countries and as of today that process is almost finished.

On December 2018 we did a presentation on the TOC call:

But again no clear steps to move forward have been provided...

Moving forward and considering that we have been in the queue for a long time and we have a new TOC on board, in name of Fluentd project, I would like to ask for an official review of our Graduation proposal and further Voting process.

Since Incubation, the current statistics of Fluentd as of today are:

  • 75 official releases

  • More than 48 Million Docker Hub Pulls

  • 941 Plugins available made by the community, 917 have been updated since Incubation.

  • 7500 Github Stars

Our expectation from TOC is to get feedback if some information is missing and define the action plan for the voting process, for us be able to finish this process during April 2019 is ideal, for hence we ask to be granted with high priority in terms of revision, feedback, and final steps.

We understand new TOC have been just formed, but we trust you will understand the situation and help on this final stage.

We are happy to present again in the next TOC call if required, whatever is required from us please let us know and we will work on it with high priority too.

regards,

--

Eduardo Silva
Principal Engineer  | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . . 
m. +506 70138007
Arm.com
Treasuredata.com


   



Re: thought leadership

Sarah Allen
 

The CNCF is being looked to as a thought leader, and as I read the mission statement it seems to clearly evoke a strong leadership role “fostering and sustaining an ecosystem.”  I like Liz’s framing of the CNCF thought leadership roles as “curating, not inventing.”


To address the specific questions on security, I want to highlight some of the work of the SAFE WG, which provides a foundation for the kind of resources that I believe will be useful to executives who are making decisions about cloud native technologies and would like to understand security implications.


Published resources based on initial vision and charter:


Other in-progress resources:


We recently prioritized the security white paper, now that it is a bit more clear the audience and purpose of that resource.  We appreciate that the CNCF and the Linux Foundation is supporting this effort and look forward to collaborating with Jessica Wilkerson, Linux Foundation Cybersecurity Research Director on that effort.  


Thank you,

Sarah Allen

SAFE WG, co-chair


p.s. I completely agree on the need for more guidance on compliance (HIPAA, GDPR have come up a lot in discussions, and my hope is that the current work on shared terminology and categorization the existing technologies and common approaches for enforcement, verification, auditing, explainability, etc. will serve as a solid foundational for additional resources.)




On Fri, Mar 22, 2019 at 12:17 PM Doug Davis <dug@...> wrote:

Yup. I kind of like what we did in the Serverless WG. We produced a whitepaper and landscape doc to help people understand what serverless is all about, what's going on in the community, what's out there for people to use (OSS vs proprietary), etc... There was a little bit of opinion mixed in, but I think it was based on experience and the general direction we were seeing the community go. Or it was more like talking about design patterns that were emerging, and when they might be appropriate. It definitely was not playing "king maker" or telling people to use one product over another.

More about education than anything else so they can make an informed decision.


thanks
-Doug
_______________________________________________________
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

"Matt Farina" ---03/22/2019 02:10:22 PM---When I was writing the SIG Responsibilities I added a bullet under the end user education section th

From: "Matt Farina" <matt@...>
To: CNCF TOC <cncf-toc@...>
Date: 03/22/2019 02:10 PM
Subject: Re: [cncf-toc] thought leadership
Sent by: cncf-toc@...





When I was writing the SIG Responsibilities I added a bullet under the end user education section that reads:
      White papers, presentations, videos, or other forms of training clarifying terminology, comparisons of different approaches, available projects or products, common or recommended practises, trends, illustrative successes and failures, etc.

I don’t know if I would call this “thought leadership” in the typical sense. The idea was to consolidate and clearly communicate what is going on. To share how people are solving their problems and what it does for them.

When it comes to being opinionated on how people should do things, I tend to be a bit reserved there. Different people have different needs and there is no one size fits all. And, a lot of the talk is from infrastructure folks who have different practices, goals, and cultures from the app devs running the applications. Then there is the difference between highly regulated businesses and many of the startups trying things out. There are many dimensions to differences which makes it hard to give too many recommendations on how people should do things.

--
Matt Farina

mattfarina.com







Re: CVE Filing for OSS Projects Shut down (DWF)

Brandon Philips <bphilips@...>
 

GitHub is fine. I think someone approved my moderated message to this list quite some time after I sent it. I sent this message before filling on GitHub, and I filed on GitHub because I realized I might be moderated.

On Fri, Mar 22, 2019 at 10:19 AM Matt Klein <mattklein123@...> wrote:
Can we potentially keep the conversation about this in one place? https://github.com/cncf/toc/issues/213

It looks like what is emerging there is it's fine to directly use MITRE for now and the CNCF can consider becoming a CNA in the future?

On Fri, Mar 22, 2019 at 10:16 AM Brandon Philips <bphilips@...> wrote:
Hey TOC-

A requirement of graduation to CNCF is following the CII Criteria. And one of the requirements is having CVE numbers in release notes.

Unfortunately, two weeks ago the DWF system designed for OSS projects to generate CVE numbers shutdown. https://twitter.com/kurtseifried/status/1103858442479910913

This leaves CNCF projects in an awkward position. And I see four options:

0. CNCF becomes a CVE Numbering Authority (I have started a CNCF service desk request for this, Chris A has some thoughts)

1. Revise CII in the face of no practical CVE system for OSS projects to not have that requirement.

2. Update the CNCF Graduation criteria to not require projects to create CVEs and rely exclusively on researcher issued CVEs

3. Create a new CVE alternative that is fully distributed without a central authority. 

Thank You,

Brandon


Re: thought leadership

Doug Davis <dug@...>
 

Yup. I kind of like what we did in the Serverless WG. We produced a whitepaper and landscape doc to help people understand what serverless is all about, what's going on in the community, what's out there for people to use (OSS vs proprietary), etc... There was a little bit of opinion mixed in, but I think it was based on experience and the general direction we were seeing the community go. Or it was more like talking about design patterns that were emerging, and when they might be appropriate. It definitely was not playing "king maker" or telling people to use one product over another.

More about education than anything else so they can make an informed decision.


thanks
-Doug
_______________________________________________________
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

"Matt Farina" ---03/22/2019 02:10:22 PM---When I was writing the SIG Responsibilities I added a bullet under the end user education section th

From: "Matt Farina" <matt@...>
To: CNCF TOC <cncf-toc@...>
Date: 03/22/2019 02:10 PM
Subject: Re: [cncf-toc] thought leadership
Sent by: cncf-toc@...





When I was writing the SIG Responsibilities I added a bullet under the end user education section that reads:
      White papers, presentations, videos, or other forms of training clarifying terminology, comparisons of different approaches, available projects or products, common or recommended practises, trends, illustrative successes and failures, etc.

I don’t know if I would call this “thought leadership” in the typical sense. The idea was to consolidate and clearly communicate what is going on. To share how people are solving their problems and what it does for them.

When it comes to being opinionated on how people should do things, I tend to be a bit reserved there. Different people have different needs and there is no one size fits all. And, a lot of the talk is from infrastructure folks who have different practices, goals, and cultures from the app devs running the applications. Then there is the difference between highly regulated businesses and many of the startups trying things out. There are many dimensions to differences which makes it hard to give too many recommendations on how people should do things.

--
Matt Farina

mattfarina.com







Re: thought leadership

Quinton Hoole
 

+100 to what Liz said.

I think that the Storage and Serverless working groups have created very useful "landscape white papers" (see below) to clarify common terminology, ways to evaluate alternative approaches, and an overview of types of options available. My intention is very much to encourage the CNCF SIGs to continue to produce similar educational content (in addition to their other responsibilities).

Regarding security specifically, I have for some time been pushing the SAFE working group to produce similar content, but to my knowledge this has not happened yet.  I hope that the new still-to-be-formally-named SIG in that space will have at the top of their priority list to address that shortcoming.

Storage Landscape White Paper:

Serverless White Paper

Q
 


From: cncf-toc@... [cncf-toc@...] on behalf of Liz Rice [liz@...]
Sent: Friday, March 22, 2019 10:31 AM
To: Erin Boyd
Cc: Joe Beda; CNCF TOC
Subject: Re: [cncf-toc] thought leadership

"Thought leadership" in the sense of innovation - this fundamentally has to come from across the community. The TOC, with support and input from the new SIGs, is curating, not inventing. I doubt that's what you meant, Erin, though I can imagine a semi-fictional group of execs screaming to be told what it is they need to innovate.

"Thought leadership" In the sense of explanations - IMO a big part of "marketing" in CNCF should be about explaining to end users how to go about adopting cloud native approaches, and the various decisions that go into that. The trail map is the starting point for this today, but I do think there's more we could do here. For example, where we have multiple projects in the CNCF that serve the same or similar purpose, we could be doing more to help users decide which project suits their use case best. I'd like to see the SIGs taking on some of the content creation here. For example, it would be great to provide some high-level guidance on why you might choose, say, Envoy in some circumstances / use cases, and Linkerd in others, and perhaps a Service Mesh SIG would be the best organization to craft project- and vendor-neutral language on this. It's a difficult job, requires real knowledge of the projects but also objectivity in assessing the relative strengths of the different options, but a SIG with representatives from the different projects who come at it with the right attitude might be able to produce it. I'm just using Service Mesh-Envoy-Linkerd as an example, there are other similar cases where decisions have to be made and we don't currently provide much information.  

In the specific case of thought leadership in security, one of the things I would like to see come out of SAFE is guidance on how end user companies can achieve compliance with things like PCI or HIPAA through Cloud Native. We should be able to come up with at least some useful pointers via the expertise of a SIG, so that all our end users don't have to each come up with the same thinking independently. This is something that we discussed in the early days of SAFE and I think could be genuinely useful guidance. 

These pieces of what is essentially content creation as responsibilities that SIGs could take on in addition to liaison/delegation wrt the TOC for projects.

Totally need to agree on the need to be clear and transparent about why projects get accepted or not. My understanding (and I haven't been through this yet personally so I could have the wrong end of the stick) is that sometimes feedback has been kept private to spare the blushes of the project in question. But if projects are getting rejected and don't understand why, we should absolutely improve that. 



On Fri, Mar 22, 2019 at 9:46 PM Erin Boyd <eboyd@...> wrote:
Hi Joe,
Thanks for your insight.
Yes, I agree our job as part of this community is fostering projects where they are in the process and diversifying the landscape.
But it is as equally important to have well defined guidelines for projects to understand how to get to the next level, why they weren't accepted or even why they were as they come up for annual review. Not only does it help guide the projects, it also provides a standard by which we perform due diligence that is consistent, year over year. We have certainly had some growing pains the last few years and no doubt will continue to grow our process moving forward. It's imperative to clearly define what bar these projects are being held against and as a member of the TOC we can directly point to these criteria. My fear, as I am sure others hold, is that the initial bar was low and is increasingly becoming higher for each project and the perception of the community will be that we are kingmakers despite it all.

I am hoping the SIGs provide the technical expertise and communication back to the TOC to formulate these guidelines.  This will allow us to be 'opinionated as a community' rather than just the TOC's collective opinion.

Erin




On Fri, Mar 22, 2019 at 8:53 AM Joe Beda <jbeda@...> wrote:

Hey Erin,

 

I think a lot of us bristle at the term “thought leadership”.  One of the principles of the TOC is that we are not kingmakers – see https://github.com/cncf/toc/blob/master/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all.

 

Best practices can often be the result of trying to boil complex topics down to a one size fits all. 

 

But, honestly, I’m not sure I agree that we shouldn’t be more opinionated. That is something that I think this current TOC is considering.  How and when and what that look likes is still TBD.

 

As for the SIGs – the role of the SIGs is to assist the TOC in terms of its duties.  That primarily concerns evaluating projects for inclusion and graduation.  As part of that, forming some clear technical understanding (and documentation) on where the boundaries are and what is “cloud native” in that domain may make sense.  But producing something that is aimed at end users is, honestly, outside the scope of both the TOC and the CNCF in general.  My gut is that if there is a project that wants to do something like this they should form a project and submit it to the TOC.

 

(There is a fine line between marketing/product marketing and technical documentation.  The CNCF does have a charter to do marketing but I’m guessing what you are looking for crosses that line)

 

Other TOC members may have different views on this.

 

Joe

 

From: <cncf-toc@...> on behalf of Erin Boyd <eboyd@...>
Date: Friday, March 22, 2019 at 7:36 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] thought leadership

 

Hi All,

I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'

They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.

To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?

They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.

Thanks in advance,

Erin

 

 

--
Liz Rice
@lizrice  | lizrice.com+44 (0) 780 126 1145


Re: thought leadership

Matt Farina
 

When I was writing the SIG Responsibilities I added a bullet under the end user education section that reads:

White papers, presentations, videos, or other forms of training clarifying terminology, comparisons of different approaches, available projects or products, common or recommended practises, trends, illustrative successes and failures, etc.

I don’t know if I would call this “thought leadership” in the typical sense. The idea was to consolidate and clearly communicate what is going on. To share how people are solving their problems and what it does for them.

When it comes to being opinionated on how people should do things, I tend to be a bit reserved there. Different people have different needs and there is no one size fits all. And, a lot of the talk is from infrastructure folks who have different practices, goals, and cultures from the app devs running the applications. Then there is the difference between highly regulated businesses and many of the startups trying things out. There are many dimensions to differences which makes it hard to give too many recommendations on how people should do things.

-- 
Matt Farina
mattfarina.com




Re: thought leadership

Erin Boyd
 

Thanks Liz for pointing out my use of 'thought leadership' is not really what I intended.

I just wanted to share with the TOC that many projects/people/companies do look to the CNCF as the authoritative voice in this space. Whether or not we want to be, what we say will be construed as THE opinion/right way to do things.

And with the changes I have personally experienced the past 3 years, we have to be honest and ask ourselves if that messages has been consistent, transparent and clear. Are we providing a good balance between acceptance without king making and not also watering down what that means to be part of this foundation? Do we provide good communication to each project and the community? Can projects easily understand the process and why's? Do well have well defined criteria in each SIG category for due diligence?  These are just a few things I am personally concerned about and wanted to bring to the newly elected committee.

I am sure working together we will come up with something perfect...it's all part of the process.

Erin


On Fri, Mar 22, 2019 at 11:32 AM Liz Rice <liz@...> wrote:
"Thought leadership" in the sense of innovation - this fundamentally has to come from across the community. The TOC, with support and input from the new SIGs, is curating, not inventing. I doubt that's what you meant, Erin, though I can imagine a semi-fictional group of execs screaming to be told what it is they need to innovate.

"Thought leadership" In the sense of explanations - IMO a big part of "marketing" in CNCF should be about explaining to end users how to go about adopting cloud native approaches, and the various decisions that go into that. The trail map is the starting point for this today, but I do think there's more we could do here. For example, where we have multiple projects in the CNCF that serve the same or similar purpose, we could be doing more to help users decide which project suits their use case best. I'd like to see the SIGs taking on some of the content creation here. For example, it would be great to provide some high-level guidance on why you might choose, say, Envoy in some circumstances / use cases, and Linkerd in others, and perhaps a Service Mesh SIG would be the best organization to craft project- and vendor-neutral language on this. It's a difficult job, requires real knowledge of the projects but also objectivity in assessing the relative strengths of the different options, but a SIG with representatives from the different projects who come at it with the right attitude might be able to produce it. I'm just using Service Mesh-Envoy-Linkerd as an example, there are other similar cases where decisions have to be made and we don't currently provide much information.  

In the specific case of thought leadership in security, one of the things I would like to see come out of SAFE is guidance on how end user companies can achieve compliance with things like PCI or HIPAA through Cloud Native. We should be able to come up with at least some useful pointers via the expertise of a SIG, so that all our end users don't have to each come up with the same thinking independently. This is something that we discussed in the early days of SAFE and I think could be genuinely useful guidance. 

These pieces of what is essentially content creation as responsibilities that SIGs could take on in addition to liaison/delegation wrt the TOC for projects.

Totally need to agree on the need to be clear and transparent about why projects get accepted or not. My understanding (and I haven't been through this yet personally so I could have the wrong end of the stick) is that sometimes feedback has been kept private to spare the blushes of the project in question. But if projects are getting rejected and don't understand why, we should absolutely improve that. 



On Fri, Mar 22, 2019 at 9:46 PM Erin Boyd <eboyd@...> wrote:
Hi Joe,
Thanks for your insight.
Yes, I agree our job as part of this community is fostering projects where they are in the process and diversifying the landscape.
But it is as equally important to have well defined guidelines for projects to understand how to get to the next level, why they weren't accepted or even why they were as they come up for annual review. Not only does it help guide the projects, it also provides a standard by which we perform due diligence that is consistent, year over year. We have certainly had some growing pains the last few years and no doubt will continue to grow our process moving forward. It's imperative to clearly define what bar these projects are being held against and as a member of the TOC we can directly point to these criteria. My fear, as I am sure others hold, is that the initial bar was low and is increasingly becoming higher for each project and the perception of the community will be that we are kingmakers despite it all.

I am hoping the SIGs provide the technical expertise and communication back to the TOC to formulate these guidelines.  This will allow us to be 'opinionated as a community' rather than just the TOC's collective opinion.

Erin




On Fri, Mar 22, 2019 at 8:53 AM Joe Beda <jbeda@...> wrote:

Hey Erin,

 

I think a lot of us bristle at the term “thought leadership”.  One of the principles of the TOC is that we are not kingmakers – see https://github.com/cncf/toc/blob/master/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all.

 

Best practices can often be the result of trying to boil complex topics down to a one size fits all. 

 

But, honestly, I’m not sure I agree that we shouldn’t be more opinionated. That is something that I think this current TOC is considering.  How and when and what that look likes is still TBD.

 

As for the SIGs – the role of the SIGs is to assist the TOC in terms of its duties.  That primarily concerns evaluating projects for inclusion and graduation.  As part of that, forming some clear technical understanding (and documentation) on where the boundaries are and what is “cloud native” in that domain may make sense.  But producing something that is aimed at end users is, honestly, outside the scope of both the TOC and the CNCF in general.  My gut is that if there is a project that wants to do something like this they should form a project and submit it to the TOC.

 

(There is a fine line between marketing/product marketing and technical documentation.  The CNCF does have a charter to do marketing but I’m guessing what you are looking for crosses that line)

 

Other TOC members may have different views on this.

 

Joe

 

From: <cncf-toc@...> on behalf of Erin Boyd <eboyd@...>
Date: Friday, March 22, 2019 at 7:36 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] thought leadership

 

Hi All,

I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'

They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.

To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?

They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.

Thanks in advance,

Erin

 

 

--
Liz Rice
@lizrice  | lizrice.com+44 (0) 780 126 1145


Re: thought leadership

Liz Rice
 

"Thought leadership" in the sense of innovation - this fundamentally has to come from across the community. The TOC, with support and input from the new SIGs, is curating, not inventing. I doubt that's what you meant, Erin, though I can imagine a semi-fictional group of execs screaming to be told what it is they need to innovate.

"Thought leadership" In the sense of explanations - IMO a big part of "marketing" in CNCF should be about explaining to end users how to go about adopting cloud native approaches, and the various decisions that go into that. The trail map is the starting point for this today, but I do think there's more we could do here. For example, where we have multiple projects in the CNCF that serve the same or similar purpose, we could be doing more to help users decide which project suits their use case best. I'd like to see the SIGs taking on some of the content creation here. For example, it would be great to provide some high-level guidance on why you might choose, say, Envoy in some circumstances / use cases, and Linkerd in others, and perhaps a Service Mesh SIG would be the best organization to craft project- and vendor-neutral language on this. It's a difficult job, requires real knowledge of the projects but also objectivity in assessing the relative strengths of the different options, but a SIG with representatives from the different projects who come at it with the right attitude might be able to produce it. I'm just using Service Mesh-Envoy-Linkerd as an example, there are other similar cases where decisions have to be made and we don't currently provide much information.  

In the specific case of thought leadership in security, one of the things I would like to see come out of SAFE is guidance on how end user companies can achieve compliance with things like PCI or HIPAA through Cloud Native. We should be able to come up with at least some useful pointers via the expertise of a SIG, so that all our end users don't have to each come up with the same thinking independently. This is something that we discussed in the early days of SAFE and I think could be genuinely useful guidance. 

These pieces of what is essentially content creation as responsibilities that SIGs could take on in addition to liaison/delegation wrt the TOC for projects.

Totally need to agree on the need to be clear and transparent about why projects get accepted or not. My understanding (and I haven't been through this yet personally so I could have the wrong end of the stick) is that sometimes feedback has been kept private to spare the blushes of the project in question. But if projects are getting rejected and don't understand why, we should absolutely improve that. 



On Fri, Mar 22, 2019 at 9:46 PM Erin Boyd <eboyd@...> wrote:
Hi Joe,
Thanks for your insight.
Yes, I agree our job as part of this community is fostering projects where they are in the process and diversifying the landscape.
But it is as equally important to have well defined guidelines for projects to understand how to get to the next level, why they weren't accepted or even why they were as they come up for annual review. Not only does it help guide the projects, it also provides a standard by which we perform due diligence that is consistent, year over year. We have certainly had some growing pains the last few years and no doubt will continue to grow our process moving forward. It's imperative to clearly define what bar these projects are being held against and as a member of the TOC we can directly point to these criteria. My fear, as I am sure others hold, is that the initial bar was low and is increasingly becoming higher for each project and the perception of the community will be that we are kingmakers despite it all.

I am hoping the SIGs provide the technical expertise and communication back to the TOC to formulate these guidelines.  This will allow us to be 'opinionated as a community' rather than just the TOC's collective opinion.

Erin




On Fri, Mar 22, 2019 at 8:53 AM Joe Beda <jbeda@...> wrote:

Hey Erin,

 

I think a lot of us bristle at the term “thought leadership”.  One of the principles of the TOC is that we are not kingmakers – see https://github.com/cncf/toc/blob/master/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all.

 

Best practices can often be the result of trying to boil complex topics down to a one size fits all. 

 

But, honestly, I’m not sure I agree that we shouldn’t be more opinionated. That is something that I think this current TOC is considering.  How and when and what that look likes is still TBD.

 

As for the SIGs – the role of the SIGs is to assist the TOC in terms of its duties.  That primarily concerns evaluating projects for inclusion and graduation.  As part of that, forming some clear technical understanding (and documentation) on where the boundaries are and what is “cloud native” in that domain may make sense.  But producing something that is aimed at end users is, honestly, outside the scope of both the TOC and the CNCF in general.  My gut is that if there is a project that wants to do something like this they should form a project and submit it to the TOC.

 

(There is a fine line between marketing/product marketing and technical documentation.  The CNCF does have a charter to do marketing but I’m guessing what you are looking for crosses that line)

 

Other TOC members may have different views on this.

 

Joe

 

From: <cncf-toc@...> on behalf of Erin Boyd <eboyd@...>
Date: Friday, March 22, 2019 at 7:36 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] thought leadership

 

Hi All,

I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'

They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.

To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?

They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.

Thanks in advance,

Erin

 

 

--
Liz Rice
@lizrice  | lizrice.com+44 (0) 780 126 1145


Re: thought leadership

Cheryl Hung <chung@...>
 

Hi Erin, 

I have heard similar requests from multiple companies, so thanks for raising this. I agree that clarity would benefit the different communities involved.

I suggest the SIGs seek input from end users, and I am more than happy to facilitate. For messaging, the SIGs and CNCF staff can collaborate if/when marketing needs arise.

Cheers,
Cheryl

On Fri, Mar 22, 2019 at 4:16 PM Erin Boyd <eboyd@...> wrote:
Hi Joe,
Thanks for your insight.
Yes, I agree our job as part of this community is fostering projects where they are in the process and diversifying the landscape.
But it is as equally important to have well defined guidelines for projects to understand how to get to the next level, why they weren't accepted or even why they were as they come up for annual review. Not only does it help guide the projects, it also provides a standard by which we perform due diligence that is consistent, year over year. We have certainly had some growing pains the last few years and no doubt will continue to grow our process moving forward. It's imperative to clearly define what bar these projects are being held against and as a member of the TOC we can directly point to these criteria. My fear, as I am sure others hold, is that the initial bar was low and is increasingly becoming higher for each project and the perception of the community will be that we are kingmakers despite it all.

I am hoping the SIGs provide the technical expertise and communication back to the TOC to formulate these guidelines.  This will allow us to be 'opinionated as a community' rather than just the TOC's collective opinion.

Erin




On Fri, Mar 22, 2019 at 8:53 AM Joe Beda <jbeda@...> wrote:

Hey Erin,

 

I think a lot of us bristle at the term “thought leadership”.  One of the principles of the TOC is that we are not kingmakers – see https://github.com/cncf/toc/blob/master/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all.

 

Best practices can often be the result of trying to boil complex topics down to a one size fits all. 

 

But, honestly, I’m not sure I agree that we shouldn’t be more opinionated. That is something that I think this current TOC is considering.  How and when and what that look likes is still TBD.

 

As for the SIGs – the role of the SIGs is to assist the TOC in terms of its duties.  That primarily concerns evaluating projects for inclusion and graduation.  As part of that, forming some clear technical understanding (and documentation) on where the boundaries are and what is “cloud native” in that domain may make sense.  But producing something that is aimed at end users is, honestly, outside the scope of both the TOC and the CNCF in general.  My gut is that if there is a project that wants to do something like this they should form a project and submit it to the TOC.

 

(There is a fine line between marketing/product marketing and technical documentation.  The CNCF does have a charter to do marketing but I’m guessing what you are looking for crosses that line)

 

Other TOC members may have different views on this.

 

Joe

 

From: <cncf-toc@...> on behalf of Erin Boyd <eboyd@...>
Date: Friday, March 22, 2019 at 7:36 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] thought leadership

 

Hi All,

I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'

They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.

To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?

They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.

Thanks in advance,

Erin

 

 



--
Director of Ecosystem, Cloud Native Computing Foundation


Re: CVE Filing for OSS Projects Shut down (DWF)

Chris Aniszczyk
 

A solution is discussed on Github, let's move discussion there: https://github.com/cncf/toc/issues/213

On Fri, Mar 22, 2019 at 10:46 PM Brandon Philips <bphilips@...> wrote:
Hey TOC-

A requirement of graduation to CNCF is following the CII Criteria. And one of the requirements is having CVE numbers in release notes.

Unfortunately, two weeks ago the DWF system designed for OSS projects to generate CVE numbers shutdown. https://twitter.com/kurtseifried/status/1103858442479910913

This leaves CNCF projects in an awkward position. And I see four options:

0. CNCF becomes a CVE Numbering Authority (I have started a CNCF service desk request for this, Chris A has some thoughts)

1. Revise CII in the face of no practical CVE system for OSS projects to not have that requirement.

2. Update the CNCF Graduation criteria to not require projects to create CVEs and rely exclusively on researcher issued CVEs

3. Create a new CVE alternative that is fully distributed without a central authority. 

Thank You,

Brandon



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


Re: CVE Filing for OSS Projects Shut down (DWF)

Matt Klein
 

Can we potentially keep the conversation about this in one place? https://github.com/cncf/toc/issues/213

It looks like what is emerging there is it's fine to directly use MITRE for now and the CNCF can consider becoming a CNA in the future?

On Fri, Mar 22, 2019 at 10:16 AM Brandon Philips <bphilips@...> wrote:
Hey TOC-

A requirement of graduation to CNCF is following the CII Criteria. And one of the requirements is having CVE numbers in release notes.

Unfortunately, two weeks ago the DWF system designed for OSS projects to generate CVE numbers shutdown. https://twitter.com/kurtseifried/status/1103858442479910913

This leaves CNCF projects in an awkward position. And I see four options:

0. CNCF becomes a CVE Numbering Authority (I have started a CNCF service desk request for this, Chris A has some thoughts)

1. Revise CII in the face of no practical CVE system for OSS projects to not have that requirement.

2. Update the CNCF Graduation criteria to not require projects to create CVEs and rely exclusively on researcher issued CVEs

3. Create a new CVE alternative that is fully distributed without a central authority. 

Thank You,

Brandon


Re: thought leadership

Dan Shaw <dshaw@...>
 

Erin:

Indeed. Security has been the archetype for CNCF SIGs. We'd love to have you join the SAFE WG where we bring together implementors, platform creators and practitioners. We meet 11am PT on Fridays.

Dan Shaw
@dshaw
Always bet on Node.js ✨


On Fri, Mar 22, 2019 at 7:36 AM Erin Boyd <eboyd@...> wrote:
Hi All,
I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'
They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.
To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?
They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.
Thanks in advance,
Erin



Re: thought leadership

Joe Beda <jbeda@...>
 

Hey Erin,

 

I think a lot of us bristle at the term “thought leadership”.  One of the principles of the TOC is that we are not kingmakers – see https://github.com/cncf/toc/blob/master/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all.

 

Best practices can often be the result of trying to boil complex topics down to a one size fits all. 

 

But, honestly, I’m not sure I agree that we shouldn’t be more opinionated. That is something that I think this current TOC is considering.  How and when and what that look likes is still TBD.

 

As for the SIGs – the role of the SIGs is to assist the TOC in terms of its duties.  That primarily concerns evaluating projects for inclusion and graduation.  As part of that, forming some clear technical understanding (and documentation) on where the boundaries are and what is “cloud native” in that domain may make sense.  But producing something that is aimed at end users is, honestly, outside the scope of both the TOC and the CNCF in general.  My gut is that if there is a project that wants to do something like this they should form a project and submit it to the TOC.

 

(There is a fine line between marketing/product marketing and technical documentation.  The CNCF does have a charter to do marketing but I’m guessing what you are looking for crosses that line)

 

Other TOC members may have different views on this.

 

Joe

 

From: <cncf-toc@...> on behalf of Erin Boyd <eboyd@...>
Date: Friday, March 22, 2019 at 7:36 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] thought leadership

 

Hi All,

I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'

They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.

To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?

They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.

Thanks in advance,

Erin

 

 


CVE Filing for OSS Projects Shut down (DWF)

Brandon Philips <bphilips@...>
 

Hey TOC-

A requirement of graduation to CNCF is following the CII Criteria. And one of the requirements is having CVE numbers in release notes.

Unfortunately, two weeks ago the DWF system designed for OSS projects to generate CVE numbers shutdown. https://twitter.com/kurtseifried/status/1103858442479910913

This leaves CNCF projects in an awkward position. And I see four options:

0. CNCF becomes a CVE Numbering Authority (I have started a CNCF service desk request for this, Chris A has some thoughts)

1. Revise CII in the face of no practical CVE system for OSS projects to not have that requirement.

2. Update the CNCF Graduation criteria to not require projects to create CVEs and rely exclusively on researcher issued CVEs

3. Create a new CVE alternative that is fully distributed without a central authority. 

Thank You,

Brandon


Re: thought leadership

Erin Boyd
 

Hi Joe,
Thanks for your insight.
Yes, I agree our job as part of this community is fostering projects where they are in the process and diversifying the landscape.
But it is as equally important to have well defined guidelines for projects to understand how to get to the next level, why they weren't accepted or even why they were as they come up for annual review. Not only does it help guide the projects, it also provides a standard by which we perform due diligence that is consistent, year over year. We have certainly had some growing pains the last few years and no doubt will continue to grow our process moving forward. It's imperative to clearly define what bar these projects are being held against and as a member of the TOC we can directly point to these criteria. My fear, as I am sure others hold, is that the initial bar was low and is increasingly becoming higher for each project and the perception of the community will be that we are kingmakers despite it all.

I am hoping the SIGs provide the technical expertise and communication back to the TOC to formulate these guidelines.  This will allow us to be 'opinionated as a community' rather than just the TOC's collective opinion.

Erin




On Fri, Mar 22, 2019 at 8:53 AM Joe Beda <jbeda@...> wrote:

Hey Erin,

 

I think a lot of us bristle at the term “thought leadership”.  One of the principles of the TOC is that we are not kingmakers – see https://github.com/cncf/toc/blob/master/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all.

 

Best practices can often be the result of trying to boil complex topics down to a one size fits all. 

 

But, honestly, I’m not sure I agree that we shouldn’t be more opinionated. That is something that I think this current TOC is considering.  How and when and what that look likes is still TBD.

 

As for the SIGs – the role of the SIGs is to assist the TOC in terms of its duties.  That primarily concerns evaluating projects for inclusion and graduation.  As part of that, forming some clear technical understanding (and documentation) on where the boundaries are and what is “cloud native” in that domain may make sense.  But producing something that is aimed at end users is, honestly, outside the scope of both the TOC and the CNCF in general.  My gut is that if there is a project that wants to do something like this they should form a project and submit it to the TOC.

 

(There is a fine line between marketing/product marketing and technical documentation.  The CNCF does have a charter to do marketing but I’m guessing what you are looking for crosses that line)

 

Other TOC members may have different views on this.

 

Joe

 

From: <cncf-toc@...> on behalf of Erin Boyd <eboyd@...>
Date: Friday, March 22, 2019 at 7:36 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] thought leadership

 

Hi All,

I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'

They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.

To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?

They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.

Thanks in advance,

Erin

 

 


Re: thought leadership

alexis richardson
 

Cheryl, wdyt?


On Fri, Mar 22, 2019 at 2:39 PM Erin Boyd <eboyd@...> wrote:
Hi All,
I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'
They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.
To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?
They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.
Thanks in advance,
Erin



thought leadership

Erin Boyd
 

Hi All,
I had a call with some executives looking to understand the CNCF's role better in the industry in terms of what I could gather as 'thought leadership.'
They are looking to the CNCF to provide to them direction and best practices for things like security in the cloud native landscape.
To me, this feels like something the newly formed SIGs would be providing and not necessarily something we have today, would you all agree?
They are strongly focused on telcos and security, both of which I haven't been focused on so would like your input if I am speaking out of turn.
Thanks in advance,
Erin



Re: Technical Due Dilligence for OPA

Brendan Burns
 

btw, I heard back from Torrin, and he filed the following issues with further details on the concerns I raised:

--brendan



From: Quinton Hoole <quinton.hoole@...>
Sent: Wednesday, March 20, 2019 1:16 PM
To: Brendan Burns; cncf-toc@...
Subject: RE: Technical Due Dilligence for OPA
 
+1

Thanks for doing the hard work here Brendan and your team, and for providing such a balanced and easy-to-consume summary.  And to Torin, Tim and the rest of the OPA crew for the lucid proposal, and great project. 

Excellent to see a positive trend in outside contributions to OPA, and such rapid, broad adoption and production use.

Q


From: cncf-toc@... [cncf-toc@...] on behalf of Brendan Burns via Lists.Cncf.Io [bburns=microsoft.com@...]
Sent: Wednesday, March 20, 2019 12:28 PM
To: cncf-toc@...
Cc: cncf-toc@...
Subject: [cncf-toc] Technical Due Dilligence for OPA

Hey Folks,
I've completed my technical due-dilligence for OPA to move to incubation.

tl;dr; I'm supportive, with some plans to address a few issues.

In general, the project is in great shape along nearly all axis.

There are three areas that I think we need clarification or plan to improve from OPA as they enter incubation:

1) Some sort of old-issue cleanup. OPA doesn't have a ton of open issues (100) but some of them are very old. I think some sort of automated closing of issues is probably a good idea for hygiene.

2) Performance testing improvements. OPA is request path critical for all of it's use-cases. This means that performance is a key concern. There are some performance tests, but they don't seem comprehensive nor are they run during CI or as part of the release process as far as I can tell. I think that's an area for improvement.

3) Coverage. OPA is a security service and as such it is critical for users to have strong assurances of correctness. I'd like to see coverage metrics for unit testing, as well as aspirationally coverage for language features and validation to ensure that there aren't regressions that allow people to violate policy.

Anyway, with a plan to address these concerns, I'm supportive of OPA moving into incubator.

Happy to provide additional insight/answers as needed.

Thanks!
--brendan


4101 - 4120 of 7167