Starting the 5.0 charter process

[glenn.seiler@xxxxxxxxxxxxx (Seiler, Glenn)]

Thanks Timo;
I think I understand your proposal/process. 
I do have a couple of comments or thoughts.

1) Do you think SCOPE-Alliance will create/execute an external looking
RFP process? To-date it has been a little members-only focused, and that
is one of the things we had discussed as important back in June; to open
it more for community and ecosystem involvement.

I think, or hope, this might mean a bit more of an open gaps process
than before.

2) I wonder, again I hope, that LF would indeed become implementers of
these APIs. I know there is somewhat limited capability within LF alone,
so I still think much of the implementation has to come from other
commercial entities and individuals (i.e. distros and platform
providers). But we will have this problem regardless of whether the RFP
comes from SCOPE or LF.

3) If we actually do get real APIs defined, and then implemented, that
is great. For them to become part of LSB and then for LSB to be
something an embedded/CG distro can certify against has other issues
that the distros and LF will have to work out. Specifically what I mean
is that LSB today does not fit easily into the embedded market, but does
to a desktop or server market. This is not a new issue, but has not been
resolved to-date and will become rather acute once this whole process
starts to mature.

I am heartened by all the interest.
-glenn
 
-----Original Message-----
From: lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx
[mailto:lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of
timo.jokiaho@xxxxxxx
Sent: Friday, August 17, 2007 3:09 AM
To: lf_carrier@xxxxxxxxxxxxxxxxxxxx
Subject: RE: Starting the 5.0 charter process


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
> 
> 
>

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