Starting the 5.0 charter process

[Eric.Chacron@xxxxxxxxxxxxxxxxx (CHACRON ERIC)]

I'd like to welcome LF to setup some general meetings in Europe in the futu=
re in addition to NA. Your new office in Germany would i guess ease that.  =

 =

As SCOPE Alliance vice chair, i'd like to know if you confirm the option fo=
r Markus Rex to come to Berlin. =

In such a case we could officially invite him after our next board call sch=
eduled soon. =

 =

Eric =

 =

Alcatel-Lucent =

CTO office =

Program Manager =

+33 1 30 77 28 05
+33 6 07 24 52 81
________________________________

De : lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx [mailto:lf_carrier-bounc=
es@xxxxxxxxxxxxxxxxxxxxxxxxxx] De la part de Jim Zemlin
Envoy=E9 : vendredi 17 ao=FBt 2007 19:42
=C0 : timo.jokiaho@xxxxxxx
Cc : lf_carrier@xxxxxxxxxxxxxxxxxxxx
Objet : Re: Starting the 5.0 charter process


The LF is in the process of opening a European office in Nuremberg.   Perha=
ps our new CTO Markus Rex could pop into this meeting depending on his trav=
el 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 Intellisy=
nc
	=

	-----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.o=
rg
	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/200=
70822/6857de9e/attachment-0001.htm