From 7632c4fe46f67acf2522a63bd745fc47ec032377 Mon Sep 17 00:00:00 2001 From: Olivier Smith <61708516+Smitholi67@users.noreply.github.com> Date: Fri, 7 Jun 2024 08:37:04 -0400 Subject: [PATCH] Updates to reflect new CNTi Charter (#355) * Updates to reflect new CNTi Charter Updates to README and removal of outdated governance files that are replaced by the new CNTi Charter. * Update README.md Removed event information and added a link to common event page on CNTi wiki. This was done to reduce the number of places we need to update/maintain. --- GOVERNANCE.md | 123 ------------------------------------------ README.md | 63 ++++------------------ charter.md | 104 ----------------------------------- code-of-conduct.md | 4 -- interested-parties.md | 52 ------------------ 5 files changed, 11 insertions(+), 335 deletions(-) delete mode 100644 GOVERNANCE.md delete mode 100644 charter.md delete mode 100644 code-of-conduct.md delete mode 100644 interested-parties.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md deleted file mode 100644 index 25ca041f..00000000 --- a/GOVERNANCE.md +++ /dev/null @@ -1,123 +0,0 @@ -# Governance - -## CNTI Member Roles - -### Chairs - -The CNTI will be co-chaired by 3 people - one co-chair from the Kubernetes (K8s) Community, one from the Service Provider (SP) Community and one from the CNF Developer (Dev) Community - in order to maintain equal representation. - -- *Primary role of Chairs is governance of the group.* -- The Chairs are responsible for ensuring that group meetings are facilitated effectively, while also engaging group members in leadership roles. Effective facilitation includes the following activities: - - extending discussion via asynchronous communication to be inclusive of members who cannot attend a specific meeting time - - scheduling discussion of proposals that have been submitted - - asking for new proposals to be made to address an identified need - - partnering with Technical Leads to establish a roadmap and manage ongoing projects - -#### **Chairs - Representation** - -A maximum of one person from any one entity may hold a chair role at any given moment. See the [Independence](#independence) section for further details. - -#### **Current Co-Chairs** - -- Service Provider Co-Chair: Vacant -- CNF Developer Co-Chair: Olivier Smith, @Smitholi67 -- Kubernetes Co-Chair: Taylor Carpenter, @taylor - -Term runs 2024-01-01 to 2024-05-30 (Temporary period for the launch of CNTI) - -### Everyone else (eg. other members) - -Membership is self-declared. - -There are no membership requirements to be a part of the CNTI. This is an open public working group welcoming anyone who would like to help. - -All members - -- May either have no explicit roles or responsibilities, or formally assigned roles (see above). -- May not create the impression that they have any authority or formal responsibilities in the CNTI other than assigned roles. - - - -## Elections - -### Timeline - -Co-chairs will be elected for one year terms and may run for reelection. - -### Eligibility to Vote - -The CNTI employs "organization voting" to ensure no single organization can dominate the project. - -Individuals not associated with or employed by a company or organization are allowed one vote. Each company/organization, or related group of companies (regardless of the number of maintainers associated with or employed by that company/organization), will have a maximum of one-third representation in votes. If the results of an election result in greater than 1/3 representation, the lowest vote getters from any particular company will be removed until representation on the committee is less than one-third. - -In other words, if two contributors are employed by Company X, two by Company Y, two by Company Z, and one maintainer is an un-affiliated individual, a total of four "organization votes" are possible; one for X, one for Y, one for Z, and one for the un-affiliated individual. - -For the purpose of this document, “Company” shall mean any entity (Company-A) which controls or is controlled by another entity (Company-B) or which, together, is under the common control of a third party (Company-C), in each case where such control results from ownership, either directly or indirectly, of more than fifty percent of the voting securities or membership interests of the entity in question; and one “Company” is all of the entities that are each described above. - -Each organization listed in the [interested parties document](interested-parties.md) has one vote. Interested parties can be added at any time, but must be added at least one week before any election to have a vote. Any contributor from an organization may cast the vote for that organization. Each organization can cast one vote for a co-chair candidate in each of the communities (Kubernetes (K8s) Community, Service Provider (SP) Community, and CNF Developer (Dev) Community), three total votes. - -### Voting Procedure - -The chair for each community will be elected using [Ranked Choice Voting](https://en.wikipedia.org/wiki/Ranked_voting). - -## Independence - -The CNTI strives to maintain its editorial independence from the companies and organisations that provide its members. To this end, this charter sets limits on the involvement any given entity might have in its operation, in order to maintain the integrity of its output as a consensus view of industry technical experts. - -To this end, representation from a single entity for a given role is limited, to avoid undue influence. This section determines how companies, organisations and individual interested parties are determined to be independent of each other, and the way in which this affects elections. - -### Determination of independence - -1. An entity consists of a single company or organisation, a related group of companies or organisations in common ownership, or an individual acting independently of their employment. - -2. Entities may potentially not be independent if: - - an individual works for a company - - the ownership of two companies is not independent (one owns the other or they both are owned by a common parent, in part or in whole) - - an individual or company is under contract to another - -3. If a member raises a concern of that two entities are not independent, or, conversely, that a single entity should be considered as two separate entities, the member shall make their case and the co-chairs will consider it. - -4. If they deem the case valid, the relationship and its effects will be discussed by members. The existence of a relationship does not necessarily demonstrate that the organisations are acting in concert. - -5. A vote of all uninvolved members will be held to determine whether or not the multiple parties should be considered one entity under the rules of this charter. - -### Reconsidering the decision - -The decision on independence or dependence of entities may be revisited after a period of not less than three months. After this time, any member may raise it for discussion via the above process. - -### Change of affiliation - -The affiliations of members can change over time, both through the above process and via job changes, mergers and divestments, and so on. - -If, through this process, an entity becomes overrepresented, members of that entity will first be asked if they wish to resign their roles in order to remain within the allotment. - -If insufficient members resign their roles, the positions held by members associated with that entity will all be put up for a special election. These positions are open both to previous holders and to any new nominees. The standard nomination and election process shall be carried out. Representatives elected though this process shall serve the remaining part of the current term. - -### Effect on representation - -After any election, the results may indicate that a particular entity is overrepresented for a role, having won more seats than the limit. In this event, the maximum number of the members belonging to that entity shall be calculated, and members belonging to the entity having the least votes will be excluded from the role until the entity is fairly represented. Where there is a tie, a coin toss or other random selection mechanism shall be used to choose who is allocated the seat. - -## Content Approval Process - -To encourage contributions, the CNTI has a more relaxed stance on changes and delegates the acceptance for most items to the community as outlined in [CONTRIBUTING.md](CONTRIBUTING.md). The small list of exceptions are listed below which require a more thorough decision making process to achieve our desired outcome of fair representation and technical excellence. - -### Delegation of default changes to community - -The process for accepting changes to content in the CNTI repository (including adding new content) for any item not in the [Additional Approval Items list](#additional-approval-items) below will follow the acceptance and approval process outlined in the [CONTRIBUTING guide](CONTRIBUTING.md). - -### Changes requiring additional approval - -Items in the Additional Approval Items list require further discussion and approval before being accepted. The decision making process for items in this list is TBD. - -#### Additional Approval Items - -1. This list -1. [Charter](charter.md) -1. [Governance](GOVERNANCE.md) -1. [Code of Conduct](code-of-conduct.md) -1. CNTI "Approved" Best Practices - - This would be Best Practices which the CNF WG promotes in an approved list. Eg. Baseline Best Practices - - Proposing a best practice is encouraged with the default process. Marking it as accepted and listing it as a CNF WG approved Best Practice requires additional review and approval. - - Potentially the [Best Practices for CNF Developers](doc/best_cnf_dev.md) will list only approved best practices or at least have a designation for which are approved vs another status. diff --git a/README.md b/README.md index 0b4e7425..8ae7d6be 100644 --- a/README.md +++ b/README.md @@ -1,69 +1,28 @@ -# Cloud Native Telecom Initiative (CNTI) Best Practices +# Cloud Native Telecom Initiative (CNTi) Best Practices -The CNTI Best Practices focus area operates under the aegis of LFN. The scope of this focus area is to define cloud native networking best practices. We collaborate with the [Test Catalog](https://wiki.lfnetworking.org/x/HgAxBw) and [Certification](https://wiki.lfnetworking.org/display/LN/3+-+Certification) focus areas who work on the implementation and mechanics of the test catalog and the definition of cloud native certifications. +The CNTi Best Practices focus area operates under the aegis of LFN. The scope of this focus area is to define cloud native networking best practices. We collaborate with the CNTi [Test Catalog](https://wiki.lfnetworking.org/x/HgAxBw) and CNTi [Certification](https://wiki.lfnetworking.org/display/LN/3+-+Certification) focus areas who work on the implementation and mechanics of the test catalog and the definition of cloud native certifications. + +The [CNTi Test Catalog](https://github.com/cnti-testcatalog/testsuite) will support testing a set of these best practices to allow developers and network operators to evaluate how well a network application follows cloud native principles and best practices. Proposals which have been adopted by the CNTi Best Practices focus area are listed in the [Best Practice Proposal](doc/cbpps/) folder. - Key areas of focus - Works with community members, projects, infra providers, CNF vendors, and end users to identify pressing cloud-native networking challenges. - - Develops vendor-neutral best practices for cloud-native infra, workloads, and other networking-related applications that want to leverage cloud-native principles. + - Develops vendor-neutral [Best Practices for CNF Developers](doc/best_cnf_dev.md) for cloud-native workloads and other networking-related applications that want to leverage cloud-native principles. - Proactively engages with LF Networking projects to identify challenges or pain points where best practices (community-agreed approaches) will add value. - Publishes community-agreed best practices. - Not in scope for this focus area - - Identifying or implementing tests for the testing catalog. - Identifying or defining cloud-native certifications. -* [Best Practices for CNF Developers](doc/best_cnf_dev.md) - -The [CNF WG Charter](charter.md) further outlines the scope of our group activities as well as intended deliverables. - -The [CNTI Test Catalog](https://github.com/cnti-testcatalog/testsuite) will support testing a set of these best practices to allow developers and network operators to evaluate how well a network application follows cloud native principles and best practices. Proposals which have been adopted by the CNTI Best Practices focus area are listed in the [Best Practice Proposal](doc/cbpps/) folder. - -## Meetings - -### Current Co-Chairs - -* Service Provider Co-Chair: Open - nominations accepted -* CNF Developer Co-Chair: Olivier Smith, [@Smitholi67](https://github.com/Smitholi67) -* Kubernetes Co-Chair: Taylor Carpenter, [@taylor](https://github.com/taylor) - -### Recurring meetings - on pause - -* **When**: TBD - -* Agenda and notes are [available](https://docs.google.com/document/d/1YFimQftjkTUsxNGTsKdakvP7cJtJgCTqViH2kwJOrsc/edit) -* Recordings of previous meetings: -[Meeting Recordings](https://wiki.lfnetworking.org/display/LN/Certification) - * [CNF WG Playlist on YouTube](https://youtube.com/playlist?list=PLj6h78yzYM2PyMYvw5wiH01hthFb0qrOn) - - * [Jan 29, 2024](https://zoom.us/rec/play/Ps4s9hR4Nktk33S6L-hMCcIuBUON2K_UxZKYDdErDZLtT_wuI77XBnKpmRI1soVgdUo_HArPfkGQHXK8.aHMYV-3lgaD_uMBk?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fzoom.us%2Frec%2Fshare%2F44Z7-aYAG5QCvH2w719qKv45L8x4ln9S6GsEs_WSh1U12tZEwAF_Ydab7R5VV_g-.TzWMrZCS_hEQ4Kk4) - - - - [Feb 5, 2024](https://zoom.us/rec/play/LF0uCZTgnbglWXPnrlw06-oWgmQ7qpXKh1PGRrpzOa3Te7OMUVGG8WI0jauLcz_OpM5M-Jzpi05qTbku.Exc5o4eQLFpdnPtv?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fzoom.us%2Frec%2Fshare%2FXIdbBRkBBz_X-qIry8AOM63DuhGgJ4BNR4_YTM5N5pV5ZIXheIdtqvBWf2SKeaF6.CNzv8_J5AyjxjWi2) - - - [Feb 12, 2024](https://zoom.us/rec/play/YOazZV2bq6qtgK0yP_cujGjfFzxMBlp2PUhVnnj1KhlzmhEJK2zvXTNtpiGtbA_eHaVFgNnV5HItnWMH.C2iLtHxkmiO7epad?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fzoom.us%2Frec%2Fshare%2F-4H-b8CthLkItEQ48ms-mREVHAD-PwtiloYPVjBHz262odsSrmafbtRp9UYZWYdH.EHyHF7owi_D7idrs) +## Governance +The [CNTi Charter](https://github.com/lfn-cnti/cnti/blob/c93c0172376ac5ccb1e50f3f82132d1478ee2ef2/CNTi%20Technical%20Charter%205-31-2024.pdf) further outlines the scope of our group activities as well as intended deliverables. -### Upcoming events -* Wednesday, May 1 • 2:00pm - 2:30pm -[Evolving Together: Cloud Native Telecom's Journey Forward - Olivier Smith, MATRIXX (CNTI)](https://sched.co/1YUsR) +## Get Involved -### Past events -* [LFN Developer & Testing Forum's LFN/CNCF CNF initiatives merge](https://wiki.lfnetworking.org/pages/viewpage.action?pageId=113213504) -* [LF Cloud Native Networking Program Alignment Workshop 2023](https://github.com/cncf/cnf-wg/blob/main/events/LF-Cloud-Native-Networking-Program-Alignment-Workshop.md#lf-cloud-native-networking-program-alignment-workshop-2023) -* [Cloud Native Telco Day - KubeCon NA 2023](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/co-located-events/cloud-native-telco-day/) -* [Cloud Native Telco Day - KubeCon EU 2023](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/cloud-native-telco-day/) -* [Telco Community Gathering - KubeCon EU 2023](https://github.com/cncf/cnf-wg/blob/main/events/telco-community-gathering-kubecon-eu-20230418.md) -* [Cloud Native Telco Day NA 2022](https://events.linuxfoundation.org/cloud-native-telco-day-north-america/program/schedule/) -* [Intro & Deep Dive to the CNF WG](https://sched.co/lV9e) at KubeCon NA 2021 -* [CNF WG: K8s Best Practices for Telco Apps](https://sched.co/iE74) at KubeCon EU 2021 -* [Cloud Native Network Functions (CNF) Working Group Kick-off](https://sched.co/fRkx) at KubeCon NA 2020 +Learn more on how to get involved by visiting the [CNTi Best Practices Wiki](https://wiki.lfnetworking.org/x/HAAxBw) -## Community +## CNTi and Industry Events -* ### Slack - - [Join us on LFN Tech Slack](https://join.slack.com/t/lfntech/shared_invite/zt-2cfymedlz-358~927JZBYfVJRMA7P9jg) - - **Channel**: #cnti-bestpractices -* ### Mailing list: - - +Learn more about [events relevant for the CNTi Community](https://wiki.lfnetworking.org/x/gwDZBw) diff --git a/charter.md b/charter.md deleted file mode 100644 index 4e7a8122..00000000 --- a/charter.md +++ /dev/null @@ -1,104 +0,0 @@ -# Cloud Native Telecom Initiative Charter - -## Introduction - -The purpose of the Cloud Native Telecom Initiative (CNTI) is to aid companies including CNF vendors, Communications Service Providers and large scale enterprises to understand and adopt best practices for cloud native networking. In doing so, the CNTI seeks to drive industry adoption of cloud native technologies. - -The CNTI operates under the aegis of LF Networking. There are three (3) focus areas in CNTI which include: - -**Best Practices** - defining cloud native and Kubernetes native best practices for telecom networking. - -**Test Suite** - developing a vendor neutral and open source testing catalog that can be used to validate a CNF's adherence to community defined best practices. - -**Certification** - developing an open source and vendor neutral cloud native networking certification program where open and closed source networking applications can be certified. - -The goals for the CNTI are: - -- Identify cloud native and Kubernetes native best practices for networking -- Determine which practices will allow networking applications to most effectively utilize Kubernetes capabilities and services -- Develop a vendor neutral testing catalog that enables CNF Developers, Service Providers, and downstream projects to verify how well a CNF adheres to cloud native best practices -- Provide an open source and vendor neutral cloud native networking certification program - -## Values - -The CNTI is driven by high technical standards, and these must be maintained. It is also important to take into account that multiple humans are participating in the project, and we must ensure that we all treat each other well. In this respect, we will honor the following values: - -- **Inclusive is better than exclusive** - -Broadly successful and useful technologies require different perspectives and skill sets, which can only be heard in a welcoming and respectful environment. Community membership is a privilege, not a right. Community members earn leadership through effort, scope, quality, quantity, and duration of contributions to the technology and the community. - -- **Evolution is better than stagnation** - -The CNTI is not meant to be a set in time standard. The best practices should continually evolve with state of the art in the Kubernetes and cloud native ecosystems. Community leaders also have a duty to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up. - -- **Commit first, improve later** - -The community thrives on contribution. A PR or suggestion for a change will move the community forward faster. Healthy disagreements are important for technical excellence, and should be accompanied with a way to move forward. We will accept good contributions and continue to make them better later. - -- **Pragmatism instead of politics** - -Our best practice recommendations should be focused on bringing value in the real world rather than in the abstract / hypothetical. These best practices will have their basis in real-world applications and use cases. - -- **Community over product or company** - -We are here as a community first, with the common goal of bringing the benefits of cloud native best practices to all its members and users everywhere. Our recommended best practices should be broadly applicable and stand-alone independently. - -- **Adherence to the [Code of Conduct](code-of-conduct.md)** - -## Mission Statement - -CNTI's mission is to simplify the creation and consumption of CNFs by publicizing best practices for their development and operation. It is committed to the following (aspirational) design ideals: - -- Portable - Cloud native workloads run everywhere -- public cloud, private cloud, bare metal, laptop -- with consistent functional behavior so that they are portable throughout the ecosystem as well as between development and production environments. -- Meet users partway - Many applications today are not cloud native, but have been working in production for decades. The WG doesn’t just cater to purely greenfield cloud-native applications, nor does it meet all users where they are. It focuses on cloud-native applications, but provides some mechanisms to facilitate migration of monolithic and legacy applications. -- Flexible - The cloud native technology ecosystem can be consumed a la carte and (in most cases) it does not prevent you from using your own solutions in lieu of built-in systems. -- Extensible - Cloud native workloads should integrate into your environment and add the additional capabilities you need. -- Automatable - Cloud native workloads should aim to help dramatically reduce the burden of manual operations. They support both declarative control by specifying users’ desired intent via an API, as well as imperative control to support higher-level orchestration and automation. The declarative approach is key to the ecosystem’s self-healing and autonomic capabilities. -- Advance the state of the art - While the CNTI intends to drive the modernization of non-cloud-native applications, it also aspires to advance the cloud native and DevOps state of the art, such as in the participation of applications in their own management. Workloads should not be bound by the lowest common denominator of systems upon which they depend, such as container runtimes and cloud providers. - -## In Scope - -- Definition of Cloud Native Network Function (CNF) -- Cloud native best practices for the development and operations of CNFs - - Provide a list of the cloud native benefits a best practice provides - - Including dataplane CNFs -- Process around evaluating if best practices are used by a CNF -- Feedback into other related groups and specification bodies to improve CNF use cases -- Publishing metrics/white papers -- Writing tests and maintaining a test suite -- General recommendations - -## Potential Future Scope - -- Cloud native best practices for Telecom infrastructure (which run CNFs) - -## Out of Scope - -- Building Tooling -- Promotion of specific tools -- Solving external dependencies - -## Overlap and Relations with other Groups and Projects - -The CNTI sees itself as providing the upstream definition of what makes a networking application cloud native allowing downstream projects to create precise programs and/or implementations for their specific needs. This may include formal requirements or conformance tests/programs. Some of the groups who may utilize the program's deliverables are: - -- Anuket Reference Stream 2 (Reference Architecture 2 (RA2), Reference Implementation 2 (RI2) and Reference Conformance 2 (RC2)) - is focused on Kubernetes-based platforms and basic interoperability between platform and workloads. Anuket leverages the CNTI test suite for testing the cloud native requirements it has defined. - - -Networking applications and the workloads that are created with them are related to many topics in Cloud Native computing; therefore this WG may collaborate with many of the other CNCF and K8s SIGs, WGs, and projects. A few of the groups with potential interactions/collaboration are: - -- CNCF SIG App Delivery -- CNCF SIG Security -- CNCF SIG Network -- Kubernetes SIG Apps -- Kubernetes SIG Testing -- K8s Conformance WG - -## Responsibilities and Deliverables - -Responsibilities - -The LF Networking community, through CNTI, is in charge of what it means to be a Certified cloud native workload -- with a focus on networking and telecom workloads. -The CNTI creates and maintains the best practice definitions, processes, as well as policies around the certification program. It determines what best practices and cloud native principles are required to be conformant. - -Deliverables - -- Cloud native principles - framework documentation for cloud native best practices -- Networking application cloud native best practices - including documentation, test definitions, best practices -- Cloud native network function best practice program -- Cloud native networking tests as part of the CNTI test suite diff --git a/code-of-conduct.md b/code-of-conduct.md deleted file mode 100644 index 5d2ba5f4..00000000 --- a/code-of-conduct.md +++ /dev/null @@ -1,4 +0,0 @@ -# Code of Conduct - -The CNTI community follows the -[LF Code of Conduct](https://lfprojects.org/policies/code-of-conduct/). diff --git a/interested-parties.md b/interested-parties.md deleted file mode 100644 index 32613ecd..00000000 --- a/interested-parties.md +++ /dev/null @@ -1,52 +0,0 @@ -# Interested Parties - -To express your interest in the cloud native networking topics under discussion in this working group, please add your name and organization name to this document via a Pull Request. - -Being listed in this document may grant you some rights within the group, such as voting capabilities as outlined in the [Governance doc](GOVERNANCE.md). See the [contributing doc](CONTRIBUTING.md) for more information about getting involved and participating in the community. - -Note: adding yourself to this list does not imply any obligation (including legal) for you nor your organization. - -- [Philippe Robin](https://github.com/philipperobin), ARM -- [Ben Hirschberg](https://github.com/slashben), ARMO -- [Pankaj Goygal](https://github.com/pgoyal01), AT&T -- [Rabi Abdel](https://github.com/rabi-abdel), AWS -- Daniel Bernier, Bell Canada -- [Jeffrey Saelens](https://github.com/jeffsaelens), Charter Communications -- [Aiden Huang](https://github.com/Aiden128),Chunghwa Telecom -- [Ian Wells](https://github.com/iawells), Cisco -- Michal Sewera, Deutsche Telekom -- [Vuk Gojnic](https://github.com/vukg), Deutsche Telekom -- [Claudio Bartolini](https://github.com/claudiobartolini), Equinix -- [Frederick F. Kautz IV](https://github.com/fkautz), Doc.ai -- Maciej Skrocki, Google -- Randolph Chung, Google -- [mkr1481](https://github.com/mkr1481), Huawei -- [Ildiko Vancsa](https://github.com/ildikov), Open Infrastructure Foundation -- [Chitrabasu Khare](https://github.com/Cbkhare), [InfraCloud](https://github.com/infracloudio) -- [Michael Pedersen](https://github.com/michaelspedersen), Intel -- [Petar Torre](https://github.com/petorre), Intel -- [Simon Billingsley](https://github.com/sishbi), MATRIXX -- [Olivier Smith](https://github.com/Smitholi67), MATRIXX -- [Nikolay Nikolaev](https://github.com/nickolaev), Kong -- [Gergely Csatari](https://github.com/CsatariGergely), Nokia -- [Mars Toktonaliev](https://github.com/tokt), Nokia -- Cristian Calin, Orange -- [Miroslav Miklus](https://github.com/mmiklus), PANTHEON.tech -- Lisa Caywood, Red Hat -- [Shane Ronan](https://github.com/sronanrh), Red Hat -- [Tal Liron](https://github.com/tliron), Red Hat -- [Ranny Haiby](https://github.com/rannyh), Samsung -- [Victor Morales](https://github.com/electrocucaracha), Samsung -- Clément Nussbaumer, Swisscom -- [Ruben Merz](https://github.com/rmerz), Swisscom -- [Bryan Liles](https://github.com/bryanl), VMware -- Jambi Ganbar, VMware -- [Tom Kivlin](https://github.com/tomkivlin), Vodafone -- [Drew Bentley](https://github.com/agentpoyo), Vulk Coop -- [Lucina Stricko](https://github.com/lixuna), Vulk Coop -- [Taylor Carpenter](https://github.com/taylor), Vulk Coop -- [W. Watson](https://github.com/wavell), Vulk Coop -- [Sheetal Joshi](https://github.com/sheetaljoshi), AWS -- [Young Jung](https://github.com/jungy-aws), AWS -- [Sagar Kundral](https://github.com/nsagark), Nirmata -- [Rich Lopez](https://github.com/rich-l), F5