Starting the 5.0 charter process

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

Sep 10-13 ... board, planning and technical in Berlin at Nokia Siemens Netw=
orks ...

  TimoJ

---
Timo Jokiaho, +358 50 5002802, Mobile email powered by Nokia E61 Intellisync

-----Original Message-----
From: ext Jim Zemlin
Sent: 17-08-2007 19:43:07
To: ext Jim Zemlin;Chen, Terence
Cc: Jokiaho Timo (NSN - FI/Espoo);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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/200=
70817/206aaaf0/attachment-0001.htm