Starting the 5.0 charter process

[henry.turko@xxxxxxx (henry.turko@xxxxxxx)]

Jim The next SCOPE F2F meeting is on the week of September 10-13 in
Berlin Germany. Whenever you want to know the schedule of any SIG just
go to the Mountain view alliance home page and click (lower right hand)
on MVA Calendar of events or go directly to
http://www.mountainviewalliance.org/calendar.htm LF is also supposed to
(as a member of the MVA) post its events to this site.

Henry 

-----Original Message-----
From: lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx
[mailto:lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of ext
Jim Zemlin
Sent: Friday, August 17, 2007 9:43 AM
To: Chen, Terence
Cc: 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





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