Re: [eman] EMAN-REQ: the notion of importance
Brad Schoening <brads@coraid.com> Thu, 01 March 2012 16:25 UTC
Return-Path: <brads@coraid.com>
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7323121E8229 for <eman@ietfa.amsl.com>; Thu, 1 Mar 2012 08:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Level:
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9qLruzyB-zs for <eman@ietfa.amsl.com>; Thu, 1 Mar 2012 08:25:46 -0800 (PST)
Received: from server505.appriver.com (server505c.appriver.com [98.129.35.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7433821E80DF for <eman@ietf.org>; Thu, 1 Mar 2012 08:25:45 -0800 (PST)
X-Note-AR-ScanTimeLocal: 3/1/2012 10:25:44 AM
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: Too many policies to list
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @coraid.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed:
X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 98.129.35.1
X-Note-Reverse-DNS:
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G237 G238 G239 G240 G244 G245 G256 G347
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 195472664; Thu, 01 Mar 2012 10:25:44 -0600
Received: from MBX22.exg5.exghost.com ([169.254.1.210]) by HT05.exg5.exghost.com ([98.129.23.150]) with mapi; Thu, 1 Mar 2012 10:25:41 -0600
From: Brad Schoening <brads@coraid.com>
To: Juergen Quittek <Quittek@neclab.eu>, Benoit Claise <bclaise@cisco.com>
Date: Thu, 01 Mar 2012 10:25:40 -0600
Thread-Topic: [eman] EMAN-REQ: the notion of importance
Thread-Index: Acz3x/F9SOKGPnFyRNqYnGfJ4pJljg==
Message-ID: <CB74E1E0.22020%brads@coraid.com>
In-Reply-To: <CB7555B9.45CEF%quittek@neclab.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] EMAN-REQ: the notion of importance
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 16:25:48 -0000
Juergen, Power shedding is probably a more accurate term for the use cases here for priority/importance than just simply power down. There are many things in a commercial setting that can be turned down, but not necessarily off. Things such as variable speed fans, battery chargers, etc. On 3/1/12 7:53 AM, "Juergen Quittek" <Quittek@neclab.eu> wrote: >Hi Benoit, > >I would like to standardize a mechanism, in this case the power down >priority. That's what standards do. I do not see reason to limit >the application of the mechanism (power down priority) to a single >Use case (power down less business relevant devices first). > >Why should the IETF do so? Our task is to define useful mechanisms. >I do not like excluding other use cases. Take for example a network >with two kinds of devices: > - a few devices consuming a lot of energy and having high energy > saving potential > - a huge amount of devices with low power demand and very little > Power saving potential when turned to sleep mode. > >Even if the business importance of the few major power consumers >is higher than the business importance of the many small devices, >an energy manager may decide to achieve its power saving objectives >easier by powering down a just few main energy consumers instead of >powering down myriads of small devices that only marginally >contribute to energy saving. > >We can't foresee constraints to be considered for powering down >Devices. Giving the operator a "priority" allows the operator >to implement any scheme, may it be based on importance or mot. > >Thanks, > Juergen > > >On 01.03.12 16:03, "Benoit Claise" <bclaise@cisco.com> wrote: > >> >> >> >> Juergen, Rolf, John >> >> Looking at Rolf's feedback: >> >> I thought this is what you refer to as importance. If you have to >>switch >>something off because you cannot power all devices and you have to decide >>between 911 services or the phone in the janitors office, the priority >>will tell you. So this is EMAN and I think we can say that, whatever this >>object means it has to do with energy and I agree with your example that >>it helps you to decide what to power-off first in case you need to/want >>to. If this is what importance means (I personally would still call it >>something less ambiguous, but if we describe it better I am fine with it) >>I think it is something relevant. But you were referring to other use >>cases. Care to share more? >> >> >> Would you guys be happier with a compromise such as "business >> importance", "context importance" or "Energy Management Importance"? >> >> Expanding on Juergen's proposal: >> OLD: >> 5.1.3. Power-down priority >> >> The standard must provide means for retrieving and reporting >> power priorities of powered entities. Power-down priorities indicate >> an order in which powered entities should be switched to lower power >> states in case lower power states are desired. >> >> >> NEW: >> 5.1.3. xxxxx >> >> The standard must provide means for ranking devices in the context >> of a site or deployment, indicating which devices are more critical >> to the operation. The value is useful during peak demand when deciding >> which devices could be turned off. A ranking of devices gives an >> operator or control system a way to determine which devices should >> receive power or could be turned off for cost savings during peak >> hours of operation. In other words, if an operator is asked to turn >>off >> devices during a certain period, xxxx indicates an order in which >>powered >> entities should be switched to lower power states. >> >> >>Regarding your role proposal 5.1.2, I believe it's fine. >> >>Regards, Benoit (as a contributor) >> >> >> Dear all, >> >>The requirements draft is the first one to be agreed on. >>We can do this without having to deal with all details >>that the framework and the MIB modules can solve. >> >>In the current version draft-ietf-eman-requirements-05 there >>is a requirement >> >>OLD >> 5.1.2. Context information on powered entities >> >> The energy management standard must provide means for retrieving and >> reporting context information on powered entities, for example, tags >> associated with a powered entity that indicate the powered entity's >> role, or importance. >> >> >>Seeing the ongoing discussion I suggest separating "role" and >>"importance" >>and moving from the fuzzy term "importance" to "power-down priority". >>This would look like the following: >> >>NEW >> 5.1.2. Context information on powered entities >> >> The standard must provide means for retrieving and reporting context >> information on powered entities, for example, tags associated with a >> powered entity that indicate the powered entity's role. >> >> 5.1.3. Power-down priority >> >> The standard must provide means for retrieving and reporting >> power priorities of powered entities. Power-down priorities indicate >> an order in which powered entities should be switched to lower power >> states in case lower power states are desired. >> >>I think that the proposed requirement 5.1.3 covers Rolf's requirements >> >> >>for accurate naming and John's requirements for the functionality he >>calls "importance". >> >>Thanks, >> Juergen >> >> >>On 29.02.12 10:02, "Rolf Winter" <Rolf.Winter@neclab.eu> >><mailto:Rolf.Winter@neclab.eu> wrote: >> >> >> >> Hey John, >> >>I am not asking for an IANA registry but a good description and >>justification of importance. For most requirements it is just naturally >>clear to have them such as having the ability to monitor power states. No >>justification needed in my opinion. Then a half sentences in the document >>requires something that is called "importance". Here I see a need for a >>description and justification because it means different things to >>different people. >> >>BTW, I don't think that priority means the order in which devices need to >>be powered up. It certainly doesn’t mean that in the PoE context: >> >>"This object controls the priority of the port from the point >>of view of a power management algorithm. The priority that >>is set by this variable could be used by a control mechanism >>that prevents over current situations by disconnecting first >>ports with lower power priority. Ports that connect devices >>critical to the operation of the network - like the E911 >>telephones ports - should be set to higher priority." >> >>I thought this is what you refer to as importance. If you have to switch >>something off because you cannot power all devices and you have to decide >>between 911 services or the phone in the janitors office, the priority >>will tell you. So this is EMAN and I think we can say that, whatever this >>object means it has to do with energy and I agree with your example that >>it helps you to decide what to power-off first in case you need to/want >>to. If this is what importance means (I personally would still call it >>something less ambiguous, but if we describe it better I am fine with it) >>I think it is something relevant. But you were referring to other use >>cases. Care to share more? >> >>Best, >> >>Rolf >> >> >>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>London W3 6BL | Registered in England 2832014 >> >> >> >> >> -----Original Message----- >>From: John Parello (jparello) [mailto:jparello@cisco.com] >>Sent: Dienstag, 28. Februar 2012 20:05 >>To: Rolf Winter; Mouli Chandramouli (moulchan); Ira McDonald; Brad >>Schoening >>Cc: eman mailing list >>Subject: RE: [eman] EMAN-REQ: the notion of importance >> >>Hi Rolf, >> >>I used the terms in the email - it's defined in the framework, >>definitions and MIB. I'm not just throwing terms out I'm trying to >>help to show *you* the difference in the email text. So let's focus on >>the problem not try to discredit my word selection and transitively >>my premise in the drafts. >> >>On to the concept you're not seeing. >> >>Here's an example of the different concepts. Priority is ordering >>(precedence) like boot ordering, while importance is context >>(significance). >> >>Example: >> >>So say I have devices on my trading floor and it is completely powered >>off. I may have to power them up in a certain order based on priority >>but once they are up their running importance is different. >> >>(PRIORITY) >>Network Services >>File Services >>Software / Application Repository servers Database Servers Clients >>Access Lobby Phones Trading Phones >> >>Once they are running the importance to the business is different and >>could be >> >>(IMPORTANCE) >>Network Services (90-100) >>Trading Phones (80-90) >>File Services (70-80) >>Databases Servers (60-80) >>Client Access (30-50) >>Lobby Phones (10-30) >>Software / Application Repository Servers (1-20) >> >>The former is precedence the latter is significance. Since priority is >>already used in the PoE world for this I used "importance" to >>distinguish the concepts. Especially since the word priority us used >>for an action or process more times than for a device or thing. So >>priority IMO seemed more natural to the process or power versus a >>description of the device. >> >>Simply put importance is needed to know what you can power off during >>peak demand (but not solely that's just one very major use case) >> >>BTW Notice my use of a "fuzzy" name space for the device roles and >>importance. Not all data needs IANA registry to be useful. So "fuzzy" >>does not equal bad. Site defined guided data is extremely useful. >> >>I've used importance with nearly a dozen EnMS vendors and scores of >>vendors and it's been easy to explain versus PoE priority. Happy to >>show a running system if that clears it up. Suggest any new word you >>like for the glossary and happy to discuss and select one but let's >>make sure the concepts are retained. >> >>A bit shocked this is being debated for re-justification though as I >>first presented at IETF-78 and it's been in the drafts since then. >> >>To the Chairs: We need more input in this WG from EnMS vendors and BMS >>vendors because personally, dealing with over 100 vendors in a >>community of developers who use these concepts daily, I'm finding those >>actively participating in the group woefully not representative of >>problem space at all. We need more diverse input because these concepts >>are in common use and a call for re-justification at this point >>highlights that weakness. >> >>Perhaps a demo of existing EnMS' to help educate the WG? >> >>Jp >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >>Rolf Winter >>Sent: Tuesday, February 28, 2012 1:16 AM >>To: Mouli Chandramouli (moulchan); Ira McDonald; Brad Schoening >>Cc: eman mailing list >>Subject: Re: [eman] EMAN-REQ: the notion of importance >> >>Well let me make myself clearer then. >> >>You said: "Given the precedence of use of priority in other IETF MIBs, >>I think the value of importance is clearly illustrated." I disagree >>here because some proponents of importance state that "Priority >>describes precedence while importance describes significance. Those are >>two different concepts.". If that indeed is the case then you >>conclusion seems wrong. If priority != importance then we should >>clearly describe what importance is. I think saying importance == >>significance doesn't do the job. It is just a substitute of the word >>using a thesaurus but not a definition of how this is used and why this >>is a requirement. But please go ahead and come forward with a good >>definition of it and a good justification of it as a requirement. We >>can more concretely discuss about it then. >> >>Best, >> >>Rolf >> >> >> >> >>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>London W3 6BL | Registered in England 2832014 >> >> >> >> >> -----Original Message----- >>From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] >>Sent: Dienstag, 28. Februar 2012 10:02 >>To: Rolf Winter; Ira McDonald; Brad Schoening >>Cc: eman mailing list >>Subject: RE: [eman] EMAN-REQ: the notion of importance >> >>Rolf, >> >>I do not know what you disagree on. >> >>Initially, some folks jumped on the bandwagon it is not useful in >>Energy Management. >>And then a clear example of a similar term from the IETF PoE MIB was >>shown. >> >>Now the question is definition of the term. >> >>I had mentioned in my email, that if it is a question of a clearer >>definition of the term, that can be provided. >> >>Thanks >>Mouli >> >> >>-----Original Message----- >>From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>Sent: Tuesday, February 28, 2012 2:05 PM >>To: Mouli Chandramouli (moulchan); Ira McDonald; Brad Schoening >>Cc: eman mailing list >>Subject: RE: [eman] EMAN-REQ: the notion of importance >> >>Mouli, >> >>I disagree. There are people on the list that seem to disagree that >>importance and priority are the same concept. Just the word >> >> >> >> importance >> >> >> is utterly confusing. It could relate to security, cost, >>power-up or >>power-down priority etc. Somebody mentioned PoE and there I agree it >>is clearly defined. Importance is not. Let us first clearly define >> >> >> >> how >> >> >> it is used, then let’s make a requirement out of it in case >>the WG >>feels it should be. And let us not forget to make clear what it means >>in the context of EMAN. >> >>Best, >> >>Rolf >> >> >>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>London W3 6BL | Registered in England 2832014 >> >> >> >> >> -----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >> >> >> >> >> >> Behalf >> >> >> >> Of Mouli Chandramouli (moulchan) >>Sent: Dienstag, 28. Februar 2012 06:57 >>To: Ira McDonald; Brad Schoening >>Cc: eman mailing list >>Subject: Re: [eman] EMAN-REQ: the notion of importance >> >>Given the precedence of use of priority in other IETF MIBs, I think >>the value of importance is clearly illustrated. >> >> >> >>Regarding Role, it is not intended to be an IANA registry. This >>concept is already used by deployments. Should not be dismissed as >>not useful. >> >> >> >>If the question is – clearer description of these terms, in the >>requirements draft, it is possible to provide some text and also >> >> >> >> >> >> how >> >> >> >> these concepts can be useful. >> >> >> >>Thanks >> >>Mouli >> >> >> >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >> >> >> >> >> >> Behalf >> >> >> >> Of Ira McDonald >>Sent: Monday, February 27, 2012 11:15 PM >>To: Brad Schoening; Ira McDonald >>Cc: eman mailing list >>Subject: Re: [eman] EMAN-REQ: the notion of importance >> >> >> >>Hi, >> >>Brad - good precedent - because it makes the "importance" >>machine readable (and therefore useful). >> >>But since EMAN (and many other IETF WGs) have consistently backed >> >> >> >> away >> >> >> from any standard definition of "role" (w/ behavior >>semantics that >> >> >> >> are >> >> >> predictable), a text string of "role" is useless (except in >>a >>vendor- or site-specific manner - out-of-scope IMHO). >> >>And I suggest that the "universe of things" is too diverse to lend >>itself to an IANA registry of standard "role" keywords. >> >>Cheers, >>- Ira >> >> >>Ira McDonald (Musician / Software Architect) Chair - Linux >>Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working >>Group Co-Chair >>- IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG >>Chair >>- TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & >>Printer MIB Blue Roof Music/High North Inc >>http://sites.google.com/site/blueroofmusic<http://sites.google.com/site/b >>l >>ueroofmusic> >><http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/ >>h >>ighnorthinc<http://sites.google.com/site/highnorthinc> >><http://sites.google.com/site/highnorthinc>mailto:blueroofmusic@gmail.com >>Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO >> >> >> >> Box >> >> >> 221 Grand Marais, MI 49839 906-494-2434 >> >> >> >> >> >>On Mon, Feb 27, 2012 at 12:10 PM, Brad Schoening <brads@coraid.com> >><mailto:brads@coraid.com> >>wrote: >> >>Benoit, >> >> >> >>There is a precedence for doing this on the device in the PoE MIB, >>rfc3621 which defines pethPsePortPowerPriority: >> >> pethPsePortPowerPriority OBJECT-TYPE >> SYNTAX INTEGER { >> critical(1), >> high(2), >> low(3) >> } >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object controls the priority of the port from the >> >> >> >> >> >> point >> >> >> >> of view of a power management algorithm. The >>priority >> >> >> >> >> >> that >> >> >> >> is set by this variable could be used by a control >> >> >> >> >> >> mechanism >> >> >> >> that prevents over current situations by >>disconnecting >> >> >> >> >> >> first >> >> >> >> ports with lower power priority. Ports that >>connect >> >> >> >> >> >> devices >> >> >> >> critical to the operation of the network - like >>the E911 >> telephones ports - should be set to higher priority." >> ::= { pethPsePortEntry 7 } >> >> >> >> >> >>Brad Schoening >>e: brads@coraid.com ⟐ m: 917-304-7190 >> >> >> >> >> >> >> >> >> >> >> >> Redefining Storage Economics >> >> >> >> >> >>From: Benoit Claise <bclaise@cisco.com> <mailto:bclaise@cisco.com> >>Date: Mon, 27 Feb 2012 05:17:24 -0600 >>To: eman mailing list <eman@ietf.org> <mailto:eman@ietf.org> >>Subject: [eman] EMAN-REQ: the notion of importance >> >> >> >>Dear all, >> >>There is a discussion amongst the "EMAN requirements" authors right >>now about the notion of importance. >>We're trying to evaluate the requirements related to the >> >> >> >> >> >> "importance". >> >> >> >> The current draft version >><http://tools.ietf.org/html/draft-ietf- >> >> >> >> eman- >> >> >> requirements-05> only mentions: >> >> >>5.1.2. Context information on powered entities >> >> The energy management standard must provide means for retrieving >> >> >> >> and >> >> >> reporting context information on powered entities, for >>example, >> >> >> >> tags >> >> >> associated with a powered entity that indicate the >>powered >> >> >> >> entity's >> >> >> role, or importance. >> >> >>So there are no justifications why the importance is required. >>The people who want this, please provide some more >> >> >> >> text/justifications >> >> >> Some extra questions: >>- Is this importance specific to EMAN or is this generic also for >>non Energy Objects? >>- Importance is important related to ...? >> >>Regards, Benoit (as a contributor for the EMAN-REQ) >> >> >> >> >> >>_______________________________________________ >>eman mailing list >>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman >> >> >> >> >> _______________________________________________ >>eman mailing list >>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman >> >> >> _______________________________________________ >>eman mailing list >>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman >> >> >> _______________________________________________ >>eman mailing list >>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman >> >> >> >> >> >
- Re: [eman] EMAN-REQ: the notion of importance Brad Schoening
- [eman] EMAN-REQ: the notion of importance Benoit Claise
- Re: [eman] EMAN-REQ: the notion of importance Ira McDonald
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance Rolf Winter
- Re: [eman] EMAN-REQ: the notion of importance John Parello (jparello)
- Re: [eman] EMAN-REQ: the notion of importance Ira McDonald
- Re: [eman] EMAN-REQ: the notion of importance John Parello (jparello)
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance John Parello (jparello)
- Re: [eman] EMAN-REQ: the notion of importance Mouli Chandramouli (moulchan)
- Re: [eman] EMAN-REQ: the notion of importance Rolf Winter
- Re: [eman] EMAN-REQ: the notion of importance Mouli Chandramouli (moulchan)
- Re: [eman] EMAN-REQ: the notion of importance Rolf Winter
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance John Parello (jparello)
- Re: [eman] EMAN-REQ: the notion of importance Rolf Winter
- Re: [eman] EMAN-REQ: power up order Juergen Schoenwaelder
- Re: [eman] EMAN-REQ: power up order Rolf Winter
- Re: [eman] EMAN-REQ: power up order John Parello (jparello)
- Re: [eman] EMAN-REQ: power up order Juergen Schoenwaelder
- Re: [eman] EMAN-REQ: power up order Bruce Nordman
- Re: [eman] EMAN-REQ: power up order Juergen Schoenwaelder
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance Benoit Claise
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance Brad Schoening
- Re: [eman] EMAN-REQ: the notion of importance Benoit Claise
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance Mouli Chandramouli (moulchan)
- Re: [eman] EMAN-REQ: the notion of importance Benoit Claise
- Re: [eman] EMAN-REQ: the notion of importance Mouli Chandramouli (moulchan)
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance John Parello (jparello)
- Re: [eman] EMAN-REQ: the notion of importance David Prantl
- [eman] EMAN-REQ: the notion of importance McAndrew, Niall
- Re: [eman] EMAN-REQ: the notion of importance Benoit Claise
- Re: [eman] EMAN-REQ: the notion of importance Anthony Barrera
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek
- Re: [eman] EMAN-REQ: the notion of importance McAndrew, Niall
- Re: [eman] EMAN-REQ: the notion of importance Emmanuel Tychon
- Re: [eman] EMAN-REQ: the notion of importance Juergen Quittek