Draft CGL Re-charter

[cherry@xxxxxxxxxxxxxxxxxxxx (John Cherry)]

Hi Timo,

Dan posted a first DRAFT of the charter and I'm sure there are quite a
few tweaks that need to go into it.  To make it a bit easier to tweak
this, I put the charter draft into a wiki sandbox.

https://www.linux-foundation.org/en/Re-charter_Sandbox

Please go ahead and tweak the charter to include your view of the
LF/SCOPE relationship.  When folks have had a chance to grock the
charter a bit, we'll pull a call together to discuss it.

If anyone goes in to update the charter, please note your changes on
this list so that we all know to take a look at the changes.

Have a good weekend.

John


On Fri, 2007-08-31 at 08:20 +0300, timo.jokiaho@xxxxxxx wrote:
> Dan,
> 
> I was reading your text and looks to me that you have not seen my
> proposal or you have decided
> to discard it totally. I did not find any of my ideas from your text.
> Either way, I copy/pasted
> my proposal here for your benefit and my proposal to SCOPE will be along
> these lines:
> 
> 
> ---
> Glenn et.al
> 
> We at Nokia Siemens Networks have a firm opinion that these kind of RFPs
> should come from SCOPE Alliance (note, this is Nokia Siemens Networks
> opinion, not SCOPE at least yet).
> 
> What we also think is that collectively we should start concentrating on
> working towards consistent Carrier Grade API set within Carrier Grade OS
> domain, like CG Linux. In order to do that, the following model is
> proposed:
> 
> * LF-CGL would be primarily become implementors group with Carrier Grade
> focus.
>    SCOPE Alliance develops gap / requirement document and spells out the
> need for APIs
>    related to the gaps / requirements. This will given to LF-CGL, which
> then starts developing
>    the APIs themselves. The development process should be full consensus
> based. When the
>    APIs are defined, LF CGL includes the new APIs into LSB CGL module
> and they would
>    then be automatically included into LSB certification process.
> 
> In addition to this SCOPE would continue to profile existing API specs
> and then provides the profile (priorities) to LF-CGL group, which then
> works on those and makes sure they will be included into LSB CGL module.
> They would then be included into LSB certification process.
> ----
> 
> 
> Cheers
> 
>   TimoJ
> 
> 
> 
> -----Original Message-----
> From: lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx
> [mailto:lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of ext
> Dan Kohn
> Sent: 29 August, 2007 21:02
> To: lf_carrier@xxxxxxxxxxxxxxxxxxxx
> Subject: Draft CGL Re-charter
> 
> [* Note: My apologies that this has taken so long to publish.  I have
> tried to incorporate ideas from the list, but this is fundamentally a
> draft and comments are strongly requested.
> 
> This charter is modeled on IETF working group charters such as
> <http://www.ietf.org/html.charters/atompub-charter.html>.  We need
> volunteers for the chair and document editor roles.  Also, please check
> out the placeholder Carrier Gaps page I created based on PAA
> <http://www.linux-foundation.org/en/Carrier_Gaps>.  - dan *]
> 
> 
> DRAFT Carrier Grade Linux Re-Charter
> 
> Chair(s):
> TBD
> 
> Document Editors:
> TBD
> 
> Linux Foundation (LF) Liason:
> Dan Kohn
> 
> Workgroup pages:
> http://www.linux-foundation.org/en/Carrier_Grade_Linux
> http://www.linux-foundation.org/en/Carrier_Gaps
> 
> Mailing list:
> lf_carrier@xxxxxxxxxxxxxxxxxxxx
> https://lists.linux-foundation.org/mailman/listinfo/lf_carrier
> 
> 
> Description of Workgroup
> 
> This document lays out the new charter for the Carrier Grade Linux
> (CGL) workgroup.  The workgroup's goal is to help improve Linux to
> better meet the needs of the telecommunications industry.
> 
> The Linux community (also known as "upstream") works via collaborative,
> open development.  For the kernel, that work is debated on the Linux
> Kernel Mailing List (LKML) and documented in the git source control
> system.  A new kernel is released every 2 to 3 months, with consumer
> distros released every ~6 months, and enterprise distros every ~18
> months.  By contrast, the telecoms industry generally functions via
> Requests for Proposal (RFPs) and requirements documents.  Carrier
> systems can be installed (and require support) for 5 or even 10 years.
> This workgroup aims to help the Linux and carrier communities better
> communicate their requirements and capabilities so that Linux can better
> satisfy carriers' needs.
> 
> The workgroup will begin by taking the published CGL 4.0 documents and
> splitting them into two parts.  The "Satisfied Requirements"  
> document will include all requirements that are fully satisfied by  
> the current mainline kernel and/or latest enterprise distributions.   
> The goal is to have a formal way for the carrier community to
> communicate to their vendors and the Linux community what requirements
> they expect to continue to be satisfied over time.  This document is not
> expected to change frequently, except by having new requirements added
> to it as they are satisfied.
> 
> The second, and more dynamic document, is the "Carrier Gaps"  
> document.  This document describes carrier requirements that are not
> currently satisfied by the mainline kernel and/or latest enterprise
> distros.  Each requirement will include one or more specific examples of
> carrier needs that are not currently being satisfied.  These
> requirements should include some proof-of-concept to avoid blue-sky
> requirements.  Examples of proofs-of-concept are proposed patchsets, the
> existence in other OSes like Windows or Solaris, or existing products
> that use different approaches such as a hard RTOS.
> 
> Each section of the document will specify a requirement (what) and the
> justifications (why), but not the implementation (how).  Although
> proposing a patchset is perhaps the most efficient way of demonstrating
> a capability, the CGL workgroup does not expect to dictate what
> patchsets should be accepted.  Instead, the goal is to have kernel
> developers review and comment on these requirements on the CGL mailing
> list.  This initial round of review will hopefully reveal issues that
> need to be addressed for a patch to be accepted, or at least serve to
> illustrate the underlying requirement that carriers are aiming to solve.
> Ultimately, any proposed kernel patches must be posted on LKML and
> accepted by the relevant subsystem maintainer under the normal kernel
> development process.  The goal of CGL is to increase the early
> communication between the carrier and Linux communities to increase the
> probability that functionality needed by carriers and their vendors will
> be quickly adopted.
> 
> When the importance of a requirement is broadly agreed among the CGL
> workgroup but the proposed implementation is not acceptable or does not
> exist, the LF is open to sponsoring a contractor to develop or enhance a
> specific, focused patchset.  Ultimately, that patchset will still need
> to be accepted on LKML, but the LF can facilitate the process when no
> one vendor is willing or able to do the work.  The LF has a directed
> funding program to enable companies to support this kind of project, and
> can hire contractors without charging any overhead costs.
> 
> The "Carrier Gaps" document is expected to initially (and perhaps
> always) exist as a wiki page that can be edited by any member of the
> workgroup, although supervised by a document editor.  It's at <http://
> www.linux-foundation.org/en/Carrier_Gaps>.  The aim is to dramatically
> lower the cycle times between the carrier community requesting
> functionality and the kernel community commenting on the features and/or
> implementing them.  Rather than waiting for a lengthy publishing
> process, the idea is to use the Carrier Gaps document as a living
> repository of the status of different projects and the interaction with
> the kernel community.  As functionality is implemented, the section
> would be moved to the Satisfied Requirements document.  Functionality
> that is likely never to be implemented can, after discussion, be listed
> in a special section at the bottom to explain the history of the request
> and the negative response from the kernel community.
> 
> While interactions with the kernel community are the initial focus of
> the workgroup, this format is expected to extend to other upstream
> communities as well.
> 
> 
> Interactions with SCOPE
> 
> The CGL workgroup is eager not to duplicate or conflict with the work of
> the SCOPE Alliance <http://www.scope-alliance.org/>.  The LF is the
> standardization and certification authority for Linux.  SCOPE "is an
> industry alliance committed to accelerating the deployment of carrier
> grade base platforms for service provider applications".  CGL documents
> can and generally will be issued as LF standards.  SCOPE does not write
> standards itself, but publishes profiles of other organization's
> standards.
> 
> The goal of CGL is to be an upstream standards group providing standards
> that SCOPE can recommend.  This can most efficiently be accomplished by
> having SCOPE members participate directly in the CGL Workgroup, so that
> by the time the output gets to SCOPE, most potential conflicts will have
> been resolved.  In particular, it is expected that the Satisfied
> Requirements document will be the best source for SCOPE to cite.  SCOPE
> members participating in CGL will be assumed to be representing their
> own company's interests unless they explicitly state that they are
> speaking for SCOPE.  That enables SCOPE members to engage in early
> participation while reserving official acceptance of a standard to the
> SCOPE board.
> 
> 
> LSB Modules
> 
> The Linux Standard Base supports the implementation of optional modules
> specifying certain functionality.  In most cases, that functionality
> would need to have an associated test suite.  If the CGL workgroup
> decides it would be useful, construction of a CGL LSB module could
> enable a more rigorous certification process.  However, any LSB work is
> initially out of scope of the workgroup, and will require an update of
> this charter to initiate.
> 
> 
> Governance
> 
> The Governance of CGL will begin very lightweight.  If contentious
> issues arise, we can move to a heavier-weight structure, such as that
> used by the LSB <http://www.linux-foundation.org/en/
> LSB_Charter#Leadership_and_Governance>.
> 
> The workgroup is led by one or more chairpersons, who are appointed by
> the LF Executive Director with the advice of the workgroup.
> 
> The workgroup operates on an IETF-like "rough consensus" model.  
> "Rough consensus" is determined by the chair.  Decisions by the chair
> which contributors believe do not reflect rough consensus may be
> appealed first to the chair, then to the LF Executive Director, and
> finally to the LF board.
> 
> Workgroup business is conducted in an open forum (typically a wiki,
> mailing lists, conference calls, and periodic face-to-face meetings).  
> Membership in the workgroup is open. Decisions must be clearly
> documented in that open forum along with any outstanding issues, which
> may be used as the basis for further discussion.
> 
> Certification/registration services may be restricted to LF members.   
> Exceptions will generally be made for non-profit projects like Debian.
> 
> The chair, with the advice of the workgroup, will appoint one or more
> document editors.  The chair will work with the LF Liason to request and
> organize any LF resources to assist with the workgroup's activities.
> 
> Adoption of this charter and future updates to it require rough
> consensus of the working group.
> 
> 
> Goals and Milestones
> 
> September 2007		At least 10 requirements moved from CGL 4.0
> document  
> to Carrier Gaps
> October 2007		Satisfied Requirements draft
> October 2007		Initial reaction from kernel developers on at
> least 3  
> requirements
> November 2007		Re-evaluate new workgroup structure and set new
> 
> milestones
> 
> 
> Published Documents
> 
> CGL 4.0 Documents <http://www.linux-foundation.org/en/
> Carrier_Grade_Linux>
> Carrier Gaps <http://www.linux-foundation.org/en/Carrier_Gaps>
> 
> 
>             - dan