Starting the 5.0 charter process

[jzemlin@xxxxxxxxxxxxxxxxxxxx (Jim Zemlin)]

The LF is in the process of opening a European office in Nuremberg.    
Perhaps our new CTO Markus Rex could pop into this meeting depending  
on his travel schedule.   Would that be helpful in terms of defining  
this relationship?

Jim

On Aug 17, 2007, at 10:26 AM, <timo.jokiaho@xxxxxxx> wrote:

>
> Yes, this is accurete ...
>
>   TimoJ
>
> ---
> Timo Jokiaho, +358 50 5002802, Mobile email powered by Nokia E61  
> Intellisync
>
> -----Original Message-----
> From: ext John Cherry
> Sent: 17-08-2007 20:15:10
> To: ext John Cherry;Chen, Terence
> Cc: Jim Zemlin;Jokiaho Timo (NSN - FI/Espoo);lf_carrier@linux- 
> foundation.org
> Subject: RE: Starting the 5.0 charter process
>
>
> On Fri, 2007-08-17 at 10:02 -0700, Chen, Terence wrote:
> > >When is the next set of SCOPE meetings?
> >
> > Timo,
> >
> > Do you have SCOPE meetings schedule?
>
> According to the SCOPE site, the upcoming meetings are...
>
> Sept 10-13, Berlin (Nokia Siemens Networks)
>    Board meetings - Sept 10-11
>    Tech meetings - Sept 12-13
>
> Oct 23-24, Mountain View (Nokia Siemens Networks)
>    Board meetings
>
> Nov 28-30, Tokyo (NEC Corp)
>    Annual General Meetings
>
> Is this still the plan?
>
> John
>
> >
> > -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
> > >
> > >
> >
> > _______________________________________________
> > 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/20070817/d1afecc5/attachment-0001.htm