Starting the 5.0 charter process

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

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.

Any thoughts ?

Cheers

  TimoJ


>-----Original Message-----
>From: lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx
>[mailto:lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of ext

>Seiler, Glenn
>Sent: 16 August, 2007 12:45
>To: lf_carrier@xxxxxxxxxxxxxxxxxxxx
>Subject: Starting the 5.0 charter process
>
>We need to start this process that we agreed to back in June at the LF 
>LinuxSummit.
>
>To that end I'll start by putting some concepts out for discussion 
>before starting a draft of the charter.
>
>The first and most important thing that strikes me about the new 
>charter we [loosely] agreed to in June is that it is a very fundamental

>shift from the original charter. To be more clear; the original charter

>was to define characteristics of a Carrier Grade system - some 
>existing, some not - that must be present in order for a system to be 
>defined as Carrier Grade.
>These requirements came directly from NEPS and Telecom platform 
>providers - those most knowledgeable to provide such requirements. The 
>result was a blueprint that distro's could map against and NEPs could 
>use as a sort of metric.
>
>If we move to charter to essentially specify gaps - things not in the 
>current Linux kernel and associated packages - then the document, or 
>spec, or whatever it becomes, cannot really be used to define 
>capabilities of an OS, because by definition, the requirements do not 
>exist. Ok, so maybe a distro may have a few of the 'non-existing' gaps,

>but for the most part it becomes a document that no one can really map 
>against.
>
>So the charter changes significantly; rather than a document that 
>defines the characteristics of a CG system, it now becomes a "message 
>to the industry of what Telcos need and isn't available". A wish list. 
>My fundamental question is "what value to the NEPs is a wish list"? 
>Perhaps great value.
>But I am not the right person to answer that question. Now if the 
>community reacts - either through LF, through distros and platform 
>providers, or through grass-roots projects, then this document can 
>become of great value. But if the community does not react, it becomes 
>a nice exercise.
>
>The concept of registration, or certification, or LSB module 
>essentially goes away. How do you certify or register against things 
>that do not exist yet? I suspect that will make some very happy, but I 
>think it is a great shame.
>
>So, with my preamble out of the way, and a basic question asked of the 
>key consumers of this document, here are some ideas for moving forward.
>
>1) we should create the document similar to an RFP. The RFP should come

>from LF. It should be an RFP for CG requirements not met today. This 
>process would give equal opportunity to everyone; SCOPE Alliance, 
>individuals in the community, distros and platform providers all would 
>equal opportunity to submit requirements.
>
>2) Just like an RFP, there should be a timeframe for responding.
>
>3) There should be a "maintainer" of the requirements that resolves 
>conflicting requirements, overlaps and redundancies.
>Without a 'maintainer' the process would quickly become chaos.
>
>4) The maintainer should be a neutral party, (..LF). If not, some 
>democratic process should be created to determine a maintainer.
>
>5) There should be a template that 'suggests' the way requirements 
>should be submitted. Nothing too rigid. The template should come from 
>LF, with input from this list of course.
>
>6) As we discussed in June, the requirements should be "What" 
>of requirements that do not exist today. Not the "how". 
>
>7) I'm not sure this process or document should be restricted to the 
>kernel proper. I suspect there are valid requirements in user space as 
>well.
>
>---------------------
>
>Ok, that is all I can think of now. I'm quite sure I am missing 
>something and of course, this is an open process so I expect a lot 
>comments.
>
>Regards,
>
>-glenn
>
> 
>Glenn Seiler, General Manager Linux Solutions, Wind River direct 
>+1.510.749.2122  mobile +1.831.334.4108 fax +1.510.749.2695
> 
> 
>