cncf-toc@lists.cncf.io

Re: SIG scopes

Liz Rice

#3742

Good points. I love the content ideas, Michelle.

Alois suggested a SIG chairs f2f at KubeCon to share ideas if it's possible to find a good time

Liz

Show quoted text

On 8 Nov 2019, 18:53 +0000, Joe Beda <jbeda@...>, wrote:

One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross all the lines. (example is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.

Joe

From: <cncf-toc@...> on behalf of Alex Chircop <alex.chircop@...>
Date: Friday, November 8, 2019 at 4:49 AM
To: "Quinton Hoole via Lists.Cncf.Io" <quinton=hoole.biz@...>, Liz Rice <liz@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes

Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)

In general I think SIGs should bias towards having a broader rather than a narrower scope:

A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives

Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original objective to allow the TOC to scale

This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage & co-ordinate.

Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.

Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also reflect the TOC priorities).

From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes

Thanks Liz

This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)

Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.

In summary, my personal opinion is that we need to:

1. Agree what the scope of the CNCF is.

2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).

3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.

There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.

Other ways are fine, as long as they achieve the overall goal over time.

Q

There are several possible ways to implement the above strategy.

On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:

I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.

SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.

SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.

The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.

We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope

SIGs can evolve!

So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)

There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?

Liz

--

Quinton Hoole
quinton@...

Re: SIG scopes

Joe Beda <jbeda@...>

#3741

One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross all the lines. (example is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.

Joe

From: <cncf-toc@...> on behalf of Alex Chircop <alex.chircop@...>
Date: Friday, November 8, 2019 at 4:49 AM
To: "Quinton Hoole via Lists.Cncf.Io" <quinton=hoole.biz@...>, Liz Rice <liz@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes

Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)

In general I think SIGs should bias towards having a broader rather than a narrower scope:

A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original objective to allow the TOC to scale

This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage & co-ordinate.

Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.

Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also reflect the TOC priorities).

Show quoted text

From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes

Thanks Liz

This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)

Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.

In summary, my personal opinion is that we need to:

1. Agree what the scope of the CNCF is.

2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).

3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.

There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.

Other ways are fine, as long as they achieve the overall goal over time.

Q

There are several possible ways to implement the above strategy.

On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:

I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.

SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
SIGs can evolve!

So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)

There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?

Liz

--

Quinton Hoole
quinton@...

Re: SIG scopes

Alex Chircop

#3740

Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)

In general I think SIGs should bias towards having a broader rather than a narrower scope:

A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original objective to allow the TOC to scale

This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage & co-ordinate.

Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.

Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also reflect the TOC priorities).

Show quoted text

From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes

Thanks Liz

This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)

Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.

In summary, my personal opinion is that we need to:

1. Agree what the scope of the CNCF is.

2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).

3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.

There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.

Other ways are fine, as long as they achieve the overall goal over time.

Q

There are several possible ways to implement the above strategy.

On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:

I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.

SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
SIGs can evolve!

So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)

There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?

Liz

--

Quinton Hoole
quinton@...

Re: SIG scopes

Quinton Hoole <quinton@...>

#3739

Thanks Liz

This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)

Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.

In summary, my personal opinion is that we need to:

1. Agree what the scope of the CNCF is.

2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).

3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.

There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.

Other ways are fine, as long as they achieve the overall goal over time.

Q

There are several possible ways to implement the above strategy.

Show quoted text

On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:

I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.

SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.

SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.

The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.

We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope

SIGs can evolve!

So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)

There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?

Liz

--

Quinton Hoole
quinton@...

Re: SIG scopes

Michelle Noorali

#3738

Thanks for sharing your thoughts on this Liz. I agree with your bullet points especially around acknowledging that there are gaps and that the TOC is responsible when it comes to gaps (was just chatting with Quinton about this today). I'd like to talk further on that topic of gaps when we meet in person and how to tactically handle them.

Here are some suggestions on getting people involved in SIGs to get the conversation rolling:

Let's propose getting some content around SIGs (what they are, how to get involved, why someone may want to get involved) on the cncf.io website maybe under the "People" tab.
Priorities (milestones, project boards), backlog items (issues), issue labels ("help wanted", "good first issue"), and on-boarding/contributing docs really help with getting people involved in open source projects, so perhaps we can learn from that and build some guidance for SIG chairs and SIG repos around patterns that will help lower the barrier to entry for getting people involved in their SIGs.

Michelle

Show quoted text

From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via Lists.Cncf.Io <liz=lizrice.com@...>
Sent: Thursday, November 7, 2019 2:00 PM
To: cncf-toc@... <cncf-toc@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [cncf-toc] SIG scopes

I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.

SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
SIGs can evolve!

So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)

There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?

Liz

SIG scopes

Liz Rice

#3737

I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.

SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
SIGs can evolve!

So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)

There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?

Liz

Re: File systems unfit as distributed storage backends

Alex Chircop

#3736

It is indeed an interesting paper - metadata management, overwrites vs COW etc ... are all common problems with distributed storage solutions 🙂

Show quoted text

From: Alexis Richardson <alexis@...>
Sent: 06 November 2019 21:24
To: Alexis Richardson via cncf-toc <cncf-toc@...>; Alex Chircop <alex.chircop@...>
Subject: File systems unfit as distributed storage backends

https://blog.acolyer.org/2019/11/06/ceph-evolution/

Mboi to storage fans :)

Re: Falco DD & Request for Incubation Vote

Kris Nova <kris.nova@...>

#3735

Okay thanks for clarifying! Standing by if we can help.

—

Kris Nova

Chief Open Source Advocate

Show quoted text

On 6 Nov 2019, at 21:22, Alexis Richardson <alexis@...> wrote:

Previously we have had a period of general review, and then set a future date for a vote to ensure people make an effort to get comments in. A bit like preparing for an exam I guess.

Keep an eye on this list and your GH issue, as community comments may appear.

On Wed, 6 Nov 2019, 21:15 Kris Nova, <kris.nova@...> wrote:
Hey all,

Also a quick point of clarification - are we on standby until further notice with a formal vote? Unsure what we mean when we say “set a timeline”?

—
Kris Nova
Chief Open Source Advocate

> On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@...> wrote:
>
> Hey all,
>
> Strong +1 with Joe/Alexis
>
> Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.
>
> Thanks for your time and consideration here.
>
> —
> Kris Nova
> Chief Open Source Advocate
>
>
>> On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:
>>
>> Echoing Joe's call and amplifying to the TOC Contributors. With
>> Kubecon around the corner, I am sure almost everyone is jammed.
>>
>>> On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
>>> <jbeda=vmware.com@...> wrote:
>>>
>>> Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
>>>
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>> From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
>>> Date: Wednesday, November 6, 2019 at 4:10 AM
>>> To: CNCF TOC <cncf-toc@...>
>>> Subject: [cncf-toc] Falco DD & Request for Incubation Vote
>>>
>>>
>>>
>>> TOC members;
>>>
>>>
>>>
>>> Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
>>>
>>>
>>>
>>> As a reminder, our goals in moving to incubation include:
>>>
>>>
>>>
>>> * Moving Falco's build and release infrastructure to CNCF provided infrastructure.
>>>
>>> * Capturing and building on the current momentum of the project.
>>>
>>> * Publishing of end user case studies.
>>>
>>> * Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
>>>
>>>
>>>
>>> Falco Due Diligence:
>>>
>>> https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
>>>
>>>
>>>
>>> Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
>>>
>>> https://sysdig.com/blog/understanding-common-library-implementation/
>>>
>>>
>>>
>>> Falco PR for Incubation:
>>>
>>> https://github.com/cncf/toc/pull/307
>>>
>>>
>>>
>>> Current Falco Release:
>>>
>>> https://github.com/falcosecurity/falco/releases/tag/0.18.0
>>>
>>>
>>>
>>>
>>>
>>> We look forward to feedback from the TOC and broader community.
>>>
>>>
>>>
>>> The Falco Team
>>>
>>>
>>
>>
>>

File systems unfit as distributed storage backends

alexis richardson

#3734

https://blog.acolyer.org/2019/11/06/ceph-evolution/

Mboi to storage fans :)

Re: Falco DD & Request for Incubation Vote

alexis richardson

#3733

Previously we have had a period of general review, and then set a future date for a vote to ensure people make an effort to get comments in. A bit like preparing for an exam I guess.

Keep an eye on this list and your GH issue, as community comments may appear.

Show quoted text

On Wed, 6 Nov 2019, 21:15 Kris Nova, <kris.nova@...> wrote:

Hey all,

Also a quick point of clarification - are we on standby until further notice with a formal vote? Unsure what we mean when we say “set a timeline”?

—
Kris Nova
Chief Open Source Advocate

> On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@...> wrote:
>
> Hey all,
>
> Strong +1 with Joe/Alexis
>
> Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.
>
> Thanks for your time and consideration here.
>
> —
> Kris Nova
> Chief Open Source Advocate
>
>
>> On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:
>>
>> Echoing Joe's call and amplifying to the TOC Contributors. With
>> Kubecon around the corner, I am sure almost everyone is jammed.
>>
>>> On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
>>> <jbeda=vmware.com@...> wrote:
>>>
>>> Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
>>>
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>> From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
>>> Date: Wednesday, November 6, 2019 at 4:10 AM
>>> To: CNCF TOC <cncf-toc@...>
>>> Subject: [cncf-toc] Falco DD & Request for Incubation Vote
>>>
>>>
>>>
>>> TOC members;
>>>
>>>
>>>
>>> Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
>>>
>>>
>>>
>>> As a reminder, our goals in moving to incubation include:
>>>
>>>
>>>
>>> * Moving Falco's build and release infrastructure to CNCF provided infrastructure.
>>>
>>> * Capturing and building on the current momentum of the project.
>>>
>>> * Publishing of end user case studies.
>>>
>>> * Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
>>>
>>>
>>>
>>> Falco Due Diligence:
>>>
>>> https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
>>>
>>>
>>>
>>> Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
>>>
>>> https://sysdig.com/blog/understanding-common-library-implementation/
>>>
>>>
>>>
>>> Falco PR for Incubation:
>>>
>>> https://github.com/cncf/toc/pull/307
>>>
>>>
>>>
>>> Current Falco Release:
>>>
>>> https://github.com/falcosecurity/falco/releases/tag/0.18.0
>>>
>>>
>>>
>>>
>>>
>>> We look forward to feedback from the TOC and broader community.
>>>
>>>
>>>
>>> The Falco Team
>>>
>>>
>>
>>
>>

Re: Falco DD & Request for Incubation Vote

Kris Nova <kris.nova@...>

#3732

Hey all,

Also a quick point of clarification - are we on standby until further notice with a formal vote? Unsure what we mean when we say “set a timeline”? 

—
Kris Nova 
Chief Open Source Advocate

Show quoted text

On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@sysdig.com> wrote:

﻿Hey all,

Strong +1 with Joe/Alexis 

Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything. 

Thanks for your time and consideration here.

—
Kris Nova 
Chief Open Source Advocate 

On 6 Nov 2019, at 14:23, alexis richardson <alexis@weave.works> wrote:

﻿Echoing Joe's call and amplifying to the TOC Contributors.  With
Kubecon around the corner, I am sure almost everyone is jammed.

On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
<jbeda=vmware.com@lists.cncf.io> wrote:

Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.

Joe

From: <cncf-toc@lists.cncf.io> on behalf of Michael Ducy <michael.ducy@sysdig.com>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@lists.cncf.io>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote

TOC members;

Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.

As a reminder, our goals in moving to incubation include:

* Moving Falco's build and release infrastructure to CNCF provided infrastructure.

* Capturing and building on the current momentum of the project.

* Publishing of end user case studies.

* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.

Falco Due Diligence:

https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq

Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:

https://sysdig.com/blog/understanding-common-library-implementation/

Falco PR for Incubation:

https://github.com/cncf/toc/pull/307

Current Falco Release:

https://github.com/falcosecurity/falco/releases/tag/0.18.0

We look forward to feedback from the TOC and broader community.

The Falco Team

Re: Falco DD & Request for Incubation Vote

Kris Nova <kris.nova@...>

#3731

Hey all,

Strong +1 with Joe/Alexis 

Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything. 

Thanks for your time and consideration here.

—
Kris Nova 
Chief Open Source Advocate

Show quoted text

On 6 Nov 2019, at 14:23, alexis richardson <alexis@weave.works> wrote:

﻿Echoing Joe's call and amplifying to the TOC Contributors.  With
Kubecon around the corner, I am sure almost everyone is jammed.

On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
<jbeda=vmware.com@lists.cncf.io> wrote:

Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.

Joe

From: <cncf-toc@lists.cncf.io> on behalf of Michael Ducy <michael.ducy@sysdig.com>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@lists.cncf.io>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote

TOC members;

Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.

As a reminder, our goals in moving to incubation include:

* Moving Falco's build and release infrastructure to CNCF provided infrastructure.

* Capturing and building on the current momentum of the project.

* Publishing of end user case studies.

* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.

Falco Due Diligence:

https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq

Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:

https://sysdig.com/blog/understanding-common-library-implementation/

Falco PR for Incubation:

https://github.com/cncf/toc/pull/307

Current Falco Release:

https://github.com/falcosecurity/falco/releases/tag/0.18.0

We look forward to feedback from the TOC and broader community.

The Falco Team

Re: Falco DD & Request for Incubation Vote

alexis richardson

#3730

Echoing Joe's call and amplifying to the TOC Contributors.  With
Kubecon around the corner, I am sure almost everyone is jammed.

On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
<jbeda=vmware.com@lists.cncf.io> wrote:

Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.

Joe

From: <cncf-toc@lists.cncf.io> on behalf of Michael Ducy <michael.ducy@sysdig.com>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@lists.cncf.io>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote

TOC members;

Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.

As a reminder, our goals in moving to incubation include:

* Moving Falco's build and release infrastructure to CNCF provided infrastructure.

* Capturing and building on the current momentum of the project.

* Publishing of end user case studies.

* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.

Falco Due Diligence:

https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq

Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:

https://sysdig.com/blog/understanding-common-library-implementation/

Falco PR for Incubation:

https://github.com/cncf/toc/pull/307

Current Falco Release:

https://github.com/falcosecurity/falco/releases/tag/0.18.0

We look forward to feedback from the TOC and broader community.

The Falco Team

Re: Falco DD & Request for Incubation Vote

Joe Beda <jbeda@...>

#3729

Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.

Joe

From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote

TOC members;

Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.

As a reminder, our goals in moving to incubation include:

* Moving Falco's build and release infrastructure to CNCF provided infrastructure.

* Capturing and building on the current momentum of the project.

* Publishing of end user case studies.

* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.

Falco Due Diligence:

https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq

Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:

https://sysdig.com/blog/understanding-common-library-implementation/

Falco PR for Incubation:

https://github.com/cncf/toc/pull/307

Current Falco Release:

https://github.com/falcosecurity/falco/releases/tag/0.18.0

We look forward to feedback from the TOC and broader community.

The Falco Team

Propose to add Volcano as CNCF Sandbox

Klaus Ma

#3728

Hi team,

We'd like to propose Volcano as CNCF sandbox :)

Volcano is a Kubernetes Native Batch System, which provides features to run batch workload (e.g. AI/ML, BigData, HPC) on Kubernetes.
Please refer to PR for more detail: https://github.com/cncf/toc/pull/318

If any suggestion/comments, please let me know :)

-- Klaus

Falco DD & Request for Incubation Vote

Michael Ducy

#3726

TOC members;

Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.

As a reminder, our goals in moving to incubation include:

* Moving Falco's build and release infrastructure to CNCF provided infrastructure.

* Capturing and building on the current momentum of the project.

* Publishing of end user case studies.

* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.

Falco Due Diligence:

https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq

Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:

https://sysdig.com/blog/understanding-common-library-implementation/

Falco PR for Incubation:

https://github.com/cncf/toc/pull/307

Current Falco Release:

https://github.com/falcosecurity/falco/releases/tag/0.18.0

We look forward to feedback from the TOC and broader community.

The Falco Team

[RESULT] Vitess graduation (APPROVED)

Chris Aniszczyk

#3725

The Vitess project has been approved to the graduated maturity level:

Thanks!

--

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

Agenda for 11/05

Amye Scavarda Perrin

#3724

Hey all, we are meeting tomorrow:

https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit#heading=h.j2p1vp8nmsfk
https://docs.google.com/presentation/d/12B5dGc8lMxKeKBFS8pGoldBtZaIWBtDYUFSNcG0mnCc/edit#slide=id.g25ca91f87f_0_56

We have a review of CNCF SIGs, a review of the sandbox process, and
Harbor's Graduation Review.

-- 
Amye Scavarda Perrin | Program Manager, CNCF | amye@linuxfoundation.org

Re: Serverless WG and the AppDelivery SIG

Doug Davis <dug@...>

#3723

Quinton - Thanks for mentioning SIG-Runtime - I forgot about this suggestion. Do you think CloudEvents would be under SIG-Runtime? It mentioning orchestration and batch seems like it might fit under there. WDYT?

thanks
-Doug
_______________________________________________________
STSM | IBM Hybrid Cloud | OM Knative
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

Quinton Hoole ---11/02/2019 10:50:53 AM---I agee Liz I think serverless app development falls under sig-apps, and serveless runtimes fall unde

From: Quinton Hoole <qhoole@...>
To: Liz Rice via Lists.Cncf.Io <liz=lizrice.com@...>, Doug Davis <dug@...>, "cncf-toc@..." <cncf-toc@...>, "jbeda@..." <jbeda@...>
Date: 11/02/2019 10:50 AM
Subject: [EXTERNAL] Re: [cncf-toc] Serverless WG and the AppDelivery SIG

I agee Liz

I think serverless app development falls under sig-apps, and serveless runtimes fall under sig-runtime.
It's pretty common for work groups to span across a few SIGs.

Q

Show quoted text

From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via Lists.Cncf.Io <liz=lizrice.com@...>
Sent: Saturday, November 2, 2019 4:53 AM
To: Doug Davis <dug@...>; cncf-toc@... <cncf-toc@...>; jbeda@... <jbeda@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] Serverless WG and the AppDelivery SIG

Thanks for the reminder on this Joe.

The Serverless WG has already been performing that role of defining the landscape in their space, identifying gaps, writing white papers... The bit we’re missing is the liaison that we have between TOC and SIGs, which I for one think is valuable.

After seeing that “Topic 4” diagram I am open to the idea of broadening to SIG App Platform. I foresee some confusion between that and SIG App Delivery with those names, though. Naming is hard.

I would love to hear thoughts from more folks on the relationship between Serverless and the new Runtime SIG - we could certainly discuss on the next TOC call. Personally I don’t think SIG Runtime is a natural home for CloudEvents, function frameworks and so on, so I think there is a real gap.

But there is some overlap already: Virtual Kubelet falls into Runtime’s charter, but also appears on the Serverless landscape. Runtime feels like the more natural home; is Serverless really the right place for VK on the landscape?

Liz
On 31 Oct 2019, 15:11 +0000, Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...>, wrote:
Hey fellow TOC members – poke on this? Thoughts?

A couple of questions in my mind:

How does this relate to the proposed Runtime SIG? (https://docs.google.com/document/d/1rftGB1Wkc_VcG9gz0072uCUHIddViGtLwaO4boEb4qA/edit)
How do we look at the differences between WGs and SIGs?

Joe

From: <cncf-toc@...> on behalf of Doug Davis <dug@...>
Date: Monday, October 21, 2019 at 7:33 PM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] Serverless WG and the AppDelivery SIG

TOC members,

On a previous TOC call there was a request for feedback from the Serverless WG as to whether or not it would be a good fit for inclusion in the new AppDelivery SIG. During last week's WG call this topic was discussed and the net result is that the WG members felt that while there is some possible overlap, the scope of the WG is different enough that the SIG would not be an appropriate home for the WG. As a concrete example, it seems as though a project like CloudEvents (which came out of the WG's work) would not be in-scope for the AppDelivery SIG. With that, the WG thinks that a separate SIG might be more appropriate.

However, the creation of a Serverless SIG might be too limited in scope. One of the things that we're noticing is that the lines between CaaS, PaaS, FaaS and Serverless are getting blurry. Which means the distinction between the various platforms, or underlying technologies for each *aaS, is becoming less clear. Instead, the differences are becoming more akin to configuration settings rather than entirely distinct platform considerations. As such, the WG felt that an "AppPlatform" SIG might be more appropriate. This SIG could then focus on the underlying hosting technologies leveraged by higher-level SIGs (such as AppDelivery). It would be something along the lines of "Topic 4" in the diagram here: https://docs.google.com/document/d/1gMhRz4vEwiHa3uD8DqFKHGTSxrVJNgkLG2WZWvi9lXo/edit#bookmark=id.qv45kp7nb29b

We can discuss this on a future TOC call, but if the TOC is interested in this we can take the action item to write-up a formal charter to further clarify the proposal that we have in mind.

thanks
-Doug Davis/Mark Peek/Ken Owens

Re: Serverless WG and the AppDelivery SIG

alexis richardson

#3722

SGTM

Show quoted text

On Sat, Nov 2, 2019 at 3:31 PM Quinton Hoole <qhoole@futurewei.com> wrote:

Yes, although it probably makes most sense to house it under sig-apps if most of their attention is on the app dev part, rather than runtime infra.  One of the sigs needs to carry the can for the wg.  The WG should interact with sig-runtime regarding the runtime infra aspects.

Get Outlook for Android
________________________________
From: Alexis Richardson <alexis@weave.works>
Sent: Saturday, November 2, 2019 8:21:00 AM
To: Quinton Hoole <qhoole@futurewei.com>
Cc: Liz Rice via Lists.Cncf.Io <liz=lizrice.com@lists.cncf.io>; Doug Davis <dug@us.ibm.com>; cncf-toc@lists.cncf.io <cncf-toc@lists.cncf.io>; jbeda@vmware.com <jbeda@vmware.com>
Subject: Re: [cncf-toc] Serverless WG and the AppDelivery SIG

so:

TOC
SIG-Apps & SIG-Runtime
WG-Serverless is a 'shared' WG between the 2 SIGs

?

On Sat, Nov 2, 2019 at 3:19 PM Quinton Hoole <qhoole@futurewei.com> wrote:

I agee Liz

I think serverless app development falls under sig-apps, and serveless runtimes fall under sig-runtime.
It's pretty common for work groups to span across a few SIGs.

Q

________________________________
From: cncf-toc@lists.cncf.io <cncf-toc@lists.cncf.io> on behalf of Liz Rice via Lists.Cncf.Io <liz=lizrice.com@lists.cncf.io>
Sent: Saturday, November 2, 2019 4:53 AM
To: Doug Davis <dug@us.ibm.com>; cncf-toc@lists.cncf.io <cncf-toc@lists.cncf.io>; jbeda@vmware.com <jbeda@vmware.com>
Cc: cncf-toc@lists.cncf.io <cncf-toc@lists.cncf.io>
Subject: Re: [cncf-toc] Serverless WG and the AppDelivery SIG

Thanks for the reminder on this Joe.

The Serverless WG has already been performing that role of defining the landscape in their space, identifying gaps, writing white papers... The bit we’re missing is the liaison that we have between TOC and SIGs, which I for one think is valuable.

After seeing that “Topic 4” diagram I am open to the idea of broadening to SIG App Platform. I foresee some confusion between that and SIG App Delivery with those names, though. Naming is hard.

I would love to hear thoughts from more folks on the relationship between Serverless and the new Runtime SIG - we could certainly discuss on the next TOC call. Personally I don’t think SIG Runtime is a natural home for CloudEvents, function frameworks and so on, so I think there is a real gap.

But there is some overlap already: Virtual Kubelet falls into Runtime’s charter, but also appears on the Serverless landscape. Runtime feels like the more natural home; is Serverless really the right place for VK on the landscape?

Liz
On 31 Oct 2019, 15:11 +0000, Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@lists.cncf.io>, wrote:

Hey fellow TOC members – poke on this?  Thoughts?

A couple of questions in my mind:

How does this relate to the proposed Runtime SIG? (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1rftGB1Wkc_VcG9gz0072uCUHIddViGtLwaO4boEb4qA%2Fedit&;data=02%7C01%7Cqhoole%40futurewei.com%7C0d053b29616f4f7d5c3d08d75fa84c2b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637083048767538606&amp;sdata=8gj%2Fd42ZZdqiWwnmi6VvlnFmDkdXaidrnp6lE%2FU7ffg%3D&amp;reserved=0)
How do we look at the differences between WGs and SIGs?

At a procedural level SIGs are rooted with the TOC and seen as an extension.  WGs don’t have a formal relationship to the TOC.

Joe

From: <cncf-toc@lists.cncf.io> on behalf of Doug Davis <dug@us.ibm.com>
Date: Monday, October 21, 2019 at 7:33 PM
To: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Subject: [cncf-toc] Serverless WG and the AppDelivery SIG

TOC members,

On a previous TOC call there was a request for feedback from the Serverless WG as to whether or not it would be a good fit for inclusion in the new AppDelivery SIG. During last week's WG call this topic was discussed and the net result is that the WG members felt that while there is some possible overlap, the scope of the WG is different enough that the SIG would not be an appropriate home for the WG. As a concrete example, it seems as though a project like CloudEvents (which came out of the WG's work) would not be in-scope for the AppDelivery SIG. With that, the WG thinks that a separate SIG might be more appropriate.

However, the creation of a Serverless SIG might be too limited in scope. One of the things that we're noticing is that the lines between CaaS, PaaS, FaaS and Serverless are getting blurry. Which means the distinction between the various platforms, or underlying technologies for each *aaS, is becoming less clear. Instead, the differences are becoming more akin to configuration settings rather than entirely distinct platform considerations. As such, the WG felt that an "AppPlatform" SIG might be more appropriate. This SIG could then focus on the underlying hosting technologies leveraged by higher-level SIGs (such as AppDelivery). It would be something along the lines of "Topic 4" in the diagram here: https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1gMhRz4vEwiHa3uD8DqFKHGTSxrVJNgkLG2WZWvi9lXo%2Fedit%23bookmark%3Did.qv45kp7nb29b&;data=02%7C01%7Cqhoole%40futurewei.com%7C0d053b29616f4f7d5c3d08d75fa84c2b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637083048767538606&amp;sdata=wzylCjWw9C0D6UYG3SjCmzO%2FjigzKczvshM%2Bj8spzls%3D&amp;reserved=0

We can discuss this on a future TOC call, but if the TOC is interested in this we can take the action item to write-up a formal charter to further clarify the proposal that we have in mind.

thanks
-Doug Davis/Mark Peek/Ken Owens