Draft CGL Re-charter

[dan@xxxxxxxxxxx (Dan Kohn)]

[* 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
-- 
Dan Kohn <mailto:dan@xxxxxxxxxxx>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>