[Lf_carrier] Draft CGL Re-charter
Dan Kohn
dan at dankohn.com
Wed Aug 29 11:01:49 PDT 2007
[* 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 at linux-foundation.org
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 at dankohn.com>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/> <tel:+1-415-233-1000>
More information about the Lf_carrier
mailing list