Draft CGL Re-charter

[timo.jokiaho@xxxxxxx (timo.jokiaho@xxxxxxx)]

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


_______________________________________________
Lf_carrier mailing list
Lf_carrier@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/lf_carrier