Starting the 5.0 charter process

[terence.chen@xxxxxxxxx (Chen, Terence)]

Glenn, Timo,

I think the flow of what you described makes sense in high level;
however, it will be good for both organizations to sit down to follow
through and work out the working model to streamline the activities and
logistics such as gap analysis, requirements, implementation, and LSB
type of testing... 

The question is when and where. 

-Terence  

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