Starting the 5.0 charter process

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

>When is the next set of SCOPE meetings?

Timo,

Do you have SCOPE meetings schedule?

-Terence


>-----Original Message-----
>From: Jim Zemlin [mailto:jzemlin@xxxxxxxxxxxxxxxxxxxx]
>Sent: Friday, August 17, 2007 9:43 AM
>To: Chen, Terence
>Cc: timo.jokiaho@xxxxxxx; lf_carrier@xxxxxxxxxxxxxxxxxxxx
>Subject: Re: Starting the 5.0 charter process
>
>When is the next set of SCOPE meetings?
>
>Jim
>
>On Aug 17, 2007, at 9:06 AM, Chen, Terence wrote:
>
>> 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
>>
>> _______________________________________________
>> Lf_carrier mailing list
>> Lf_carrier@xxxxxxxxxxxxxxxxxxxxxxxxxx
>> https://lists.linux-foundation.org/mailman/listinfo/lf_carrier
>
>-------------------------------------------------
>Jim Zemlin
>Executive Director, The Linux Foundation
>210 Fell St. Suite 16
>San Francisco, CA 94102
>Cell: 415-726-2284
>Fax: 415-707-2153
>http://www.linux-foundation.org
>
>