From bnordman@lbl.gov Sun Jun 2 23:11:20 2013 Return-Path: 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 3CC2921F8E9D for ; Sun, 2 Jun 2013 23:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] 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 vAd80E4rSsJs for ; Sun, 2 Jun 2013 23:11:16 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id F0AE521F8E93 for ; Sun, 2 Jun 2013 23:11:15 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAAPEyrFHRVcC1m2dsb2JhbABWA4JFdLZHiDt2CBYOAQEBAQEGCwsJFCiCIwEBAQIBAQEBAWsEBwULCwsNLiIFDQEFARwGExqHbQYMnW+dGo12CYEYDAQHEYNHA4kgjh6BKYp3gzsWKYRVHA X-IronPort-AV: E=Sophos;i="4.87,791,1363158000"; d="scan'208";a="19161540" Received: from mail-pd0-f181.google.com ([209.85.192.181]) by fe1.lbl.gov with ESMTP; 02 Jun 2013 23:11:14 -0700 Received: by mail-pd0-f181.google.com with SMTP id bv13so5166779pdb.12 for ; Sun, 02 Jun 2013 23:11:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=e2M913pFCYYyiuD753ca6CUYJQJHKu4lp3Whd+jj05M=; b=LsU6B4yWOkZZPlkxkDciRyP69BQrLs/ewBs63arLAn1oF1J8H9hh2iNibQitnyCgl4 Qtj4Q9DQipoRzZ9apuO/FzH0u54xDutWvWuW3OHDNVASVIcOlLaIBfLgi7yCyH86d6OM KR9qhGDV5y/F1KqlERiOPUbD080Z0TJd6Xv2+dJu2gHcr98MNfsxjfC9W0ofYYnSfAQb eLSvzrzSZNZcNlZvWzLjwEtpgpXWcaSEqGtSc+AiotOf/XJ4vNv1g37ZmKUxilD08Z8v aYGmCBxo1qNvE6XcQmGEi4+kN4Pu2nkU4/GgC0n4X6yqKHdqy/fWmf/CljXPtifkpYmN o80g== X-Received: by 10.66.145.229 with SMTP id sx5mr23070709pab.11.1370239874502; Sun, 02 Jun 2013 23:11:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.145.229 with SMTP id sx5mr23070699pab.11.1370239874318; Sun, 02 Jun 2013 23:11:14 -0700 (PDT) Received: by 10.68.182.194 with HTTP; Sun, 2 Jun 2013 23:11:14 -0700 (PDT) In-Reply-To: <06C7C921-686A-466D-9ADE-6E0E1B4ED76D@cisco.com> References: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> <070.6088bf1f90de3048ca60ae728c334000@trac.tools.ietf.org> <06C7C921-686A-466D-9ADE-6E0E1B4ED76D@cisco.com> Date: Sun, 2 Jun 2013 23:11:14 -0700 Message-ID: From: Bruce Nordman To: "John Parello (jparello)" Content-Type: multipart/alternative; boundary=047d7b6781b0f7572504de39d4d9 X-Gm-Message-State: ALoCoQnKv2KcSXirJ4/QLUC+ODy064RfjpQdspTOGI/35BNilE6DlzTYD1G3EdzKYF7G1Yu3P0uZ3Z5/PB0yfKT83K+pVYd69arUavyRBbZF4TxDQjFa3G2BPDzeakjSYN+DwRj+5esf Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 06:11:20 -0000 --047d7b6781b0f7572504de39d4d9 Content-Type: text/plain; charset=ISO-8859-1 Jon-- You brought aggregation to this discussion -- I did not do so and do not see it as directly connected to powering/measurement. I am not sure what you see as missing from the requirements. You mention removing powering and metering topology modeling. I never suggested this. I did observe that there is one topology of power flows and so Powered-By and Metered-By address the same issue so redundant to have both. We can have a simpler structure which meets our needs which is only good news Thanks, --Bruce On Thu, May 30, 2013 at 3:32 PM, John Parello (jparello) wrote: > Hi Bruce, > > Yes, We are not chartered to specify coordination with the grid which > would be a protocol. FSGIM (201p) from ashrae most certainly specifies > information models not just for the grid but for facility devices as well > so you are mistaken there. > > I think you confused protocol and information models again. > > We are chartered for models for device management and we would be amiss > not to model information that ultimately would be used by EnMS' and grid > coordination systems (load summaries) > > I find Brad's reference quite relevant. Both our existing taget EnMS > users (with running code) and the quote he sites suggest imminent need for > modeling relationships between devices for power and metering. > > Also we've recognized the need for power, metering and aggregation > topologies prior to the draft of the requirements. So if your are citing > that as missing from the requirements I think you've uncovered an error in > the requirements not a justification for removing information models > pertaining to relationships between devices. > > Are you suggesting we remove power, metering, and aggregation topology > modeling? > > Jp > > Sent from my iPad > (expect ridiculous spelling mistakes) > > On May 29, 2013, at 9:12 PM, "Bruce Nordman" wrote: > > I don't follow why the ESI would be relevant to EMAN. > EMAN does not address coordination with the grid as > many standards do. Standards designed for grid > coordination (e.g. the FSGIM) have different purposes > than EMAN and different fundamental models. The > question at hand is what EMAN needs. > --Bruce > > > On Wed, May 29, 2013 at 6:38 AM, eman issue tracker < > trac+eman@trac.tools.ietf.org> wrote: > >> #36: Consider whether MeteredBy relationship is needed >> >> >> Comment (by brads@coraid.com): >> >> Other standards groups view !MeterBy and !PoweredBy as distinct logical >> functions. For example, NIST Framework and Roadmap for Smart Grid >> Interoperability Standards, Release 1.0 states: >> >> 3.5.1 Distinction between the Meter and the Energy Services Interface >> >> The meter and the ESI (Energy Services Interface) have very different >> characteristics and functions. The logical separation of the meter and >> the >> ESI is a very important forward-looking aspect of the reference model. >> .. >> While the ESI and meter are logically viewed as separate devices, >> this >> does not preclude the >> possibility for manufacturers to implement the meter and ESI in one >> physical device, provided >> that the flexibility and extensibility to support the Smart Grid >> vision can be achieved. Most smart >> meters currently integrate the ESI and meter functionality in one >> device due to cost >> considerations. Looking forward, logical separation of the two >> functions, even if physically >> integrated, is essential to avoid having the meter become an >> impediment to innovation in energy >> services enabled by the Smart Grid." >> >> >> Full Text here: >> >> http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf >> >> >> -- >> ------------------------------+-------------------- >> Reporter: bnordman@lbl.gov | Owner: Bruce >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: framework | Version: >> Severity: - | Resolution: >> Keywords: | >> ------------------------------+-------------------- >> >> Ticket URL: > > >> >> eman >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov* > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b6781b0f7572504de39d4d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jon--

You brought aggregation to thi= s discussion -- I did not do so and do
not see it as directly connected = to powering/measurement.

I am not sure what you see= as missing from the requirements.

You mention removing powering and metering topology mod= eling.
I never suggested this.=A0 I did observe that there is= one topology
of power flows and so Powered-By and Metered-By address the same issue so redundant to have both.=A0 We can
have a simpler= structure which meets our needs which is
only good news

Th= anks,

--Bruce

On Thu, May 30, 2013 at 3:32 PM, John Parell= o (jparello) <jparello@cisco.com> wrote:
Hi Bruce,

Yes, We are not chartered to specify coordination with the grid which = would be a protocol. FSGIM =A0(201p) from ashrae most certainly specifies i= nformation models not just for the grid but for facility devices as well so= you are mistaken there.

I think you confused protocol and information models again.

We are chartered for models for device management and we would be amis= s not to model information that ultimately would be used by EnMS' and g= rid coordination systems (load summaries)

=A0I find Brad's reference quite relevant. Both our existing taget= EnMS users (with running code) and =A0the quote he sites suggest imminent = need for modeling relationships between devices for power and metering.

Also we've recognized the need for power, metering and aggregation= topologies prior to the draft of the requirements. So if your are citing t= hat as missing from the requirements I think you've uncovered an error = in the requirements not a justification for removing information models pertaining to relationships between device= s.

Are you suggesting we remove power, metering, and aggregation topology= modeling?

Jp

Sent from my iPad=A0
(expect ridiculous spelling mistakes)=A0

On May 29, 2013, at 9:12 PM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

I don't follow why the ESI would be relevant to EMAN.
EMAN does not address coordination with the grid as
many standards do.=A0 Standards designed for grid
coordination (e.g. the FSGIM) have different purposes
than EMAN and different fundamental models.=A0 The
question at hand is what EMAN needs.
--Bruce


On Wed, May 29, 2013 at 6:38 A= M, eman issue tracker <trac= +eman@trac.tools.ietf.org> wrote:
#36: Consider whether MeteredBy relationship is needed


Comment (by brads@cor= aid.com):

=A0Other standards groups view !MeterBy and !PoweredBy as distinct logical<= br> =A0functions. =A0For example, NIST Framework and Roadmap for Smart Grid
=A0Interoperability Standards, Release 1.0 states:

=A03.5.1 Distinction between the Meter and the Energy Services Interface
=A0 =A0 =A0The meter and the ESI (Energy Services Interface) have very diff= erent
=A0characteristics and functions. The logical separation of the meter and t= he
=A0ESI is a very important forward-looking aspect of the reference model. =A0 =A0 =A0..
=A0 =A0 =A0While the ESI and meter are logically viewed as separate devices= , this
=A0does not preclude the
=A0 =A0 =A0possibility for manufacturers to implement the meter and ESI in = one
=A0physical device, provided
=A0 =A0 =A0that the flexibility and extensibility to support the Smart Grid=
=A0vision can be achieved. Most smart
=A0 =A0 =A0meters currently integrate the ESI and meter functionality in on= e
=A0device due to cost
=A0 =A0 =A0considerations. Looking forward, logical separation of the two =A0functions, even if physically
=A0 =A0 =A0integrated, is essential to avoid having the meter become an
=A0impediment to innovation in energy
=A0 =A0 =A0services enabled by the Smart Grid."


=A0Full Text here:
=A0http://www.nist.gov/public_af= fairs/releases/upload/smartgrid_interoperability_final.pdf


--
------------------------------+--------------------
=A0Reporter: =A0= bnordman@lbl.gov =A0| =A0 =A0 =A0 Owner: =A0Bruce
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0n= ew
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0framework =A0 =A0 =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
------------------------------+--------------------

Ticket URL: <http://trac.tools.ietf.org/wg/eman/trac/tick= et/36#comment:2>

eman <htt= p://tools.ietf.org/eman/>

_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 510-4= 86-7089
m: 51= 0-501-7943
_______________________________________________
eman mailing list
eman@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/eman



--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
nordman.lbl.gov=
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b6781b0f7572504de39d4d9-- From bnordman@lbl.gov Mon Jun 3 10:45:38 2013 Return-Path: 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 9FDED21F8FDC for ; Mon, 3 Jun 2013 10:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] 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 poa6fG6feumN for ; Mon, 3 Jun 2013 10:45:25 -0700 (PDT) Received: from fe2.lbl.gov (fe2.lbl.gov [128.3.41.134]) by ietfa.amsl.com (Postfix) with ESMTP id BBA0A21F965B for ; Mon, 3 Jun 2013 10:39:58 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwBAP/TrFHRVaAuk2dsb2JhbABWA4JFdLZPiDZ8CBYOAQEBAQcLCwkUBCSCIwEBAQIBAQEBAUYlBAcFCwsLBgMBAgEgAQ0iBQ0BBQETAQgGEwgSh2EDCQYMnhWddYxNgRgRBQSBFwEMAQMHBguDRwOJII4egSmKd4M7FimEVRyBLQgX X-IronPort-AV: E=Sophos;i="4.87,794,1363158000"; d="scan'208";a="20875869" Received: from mail-pb0-f46.google.com ([209.85.160.46]) by fe2.lbl.gov with ESMTP; 03 Jun 2013 10:39:57 -0700 Received: by mail-pb0-f46.google.com with SMTP id rq2so5992051pbb.5 for ; Mon, 03 Jun 2013 10:39:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0kNtdwpWg3lTyVE/O2HPhh3V/iAshlCZSXlF547HJv4=; b=UPNdue0edrHju+DoqMX6CKQAHg9DEUg0HjyFSB2NQj/+4Im3XZ2wfLPip0lYCW9GS0 zEWjR9/xBKm03JOWs11qTzra1CaJDaBIaN79Lw/xOYGRjftObNRW7rvL7tVnKxOrK7jK I9ZpTJk1/F9IsYYzJh4ZfkU6IJ7UY13qcmWC/dnLH7kYRq7IyEfNHgGWW7TNEmNEHBSD DOL01MFbwTnRfNWCYaV4DkTZEEAhkIsRdf5I7o7cs4nKGp6BscIDUzdMJoBOhrR+19KG 1gddd/nTzt1NI78P264tcyza8iucbXs8KoWxmwf7rNIHIe+akU8zDdGPtKdDP1aJz6gs JEaQ== X-Received: by 10.68.194.202 with SMTP id hy10mr24542603pbc.44.1370281197561; Mon, 03 Jun 2013 10:39:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.194.202 with SMTP id hy10mr24542597pbc.44.1370281197454; Mon, 03 Jun 2013 10:39:57 -0700 (PDT) Received: by 10.68.182.194 with HTTP; Mon, 3 Jun 2013 10:39:57 -0700 (PDT) In-Reply-To: <51ACAAE2.20504@verizon.net> References: <51ACAAE2.20504@verizon.net> Date: Mon, 3 Jun 2013 10:39:57 -0700 Message-ID: From: Bruce Nordman To: Brad Schoening Content-Type: multipart/alternative; boundary=047d7b10cccf04537204de43748e X-Gm-Message-State: ALoCoQnLGHOuSEMrNG+qFIEZcdrDAzPoqzfic8J+pcJg/r/4n1MdUbldex5VxP4buXP4VEe07o/sraBkriumWZPgZdHeg6ApnibYHG1XPTH+8lzBXIsfywHgIF4tAugz2n5RY95o4znC Cc: eman mailing list Subject: Re: [eman] FW: #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:45:38 -0000 --047d7b10cccf04537204de43748e Content-Type: text/plain; charset=ISO-8859-1 As a reminder, the issue tracker item in question is: "#36: Consider whether MeteredBy relationship is needed" We have powered-by and metered-by is redundant. Brad notes the Energy Services Interface concept from NIST, which page 41 of the reference he points notes: "... the Energy Services Interface (ESI), which serves as the gateway to the Customer Premises Network. " This the gateway from the Smart Grid (Utility). My comment had nothing to do with utility grids. The requirements draft does not include the words "smart" or "grid" at all, and the word "utility" only appears in the name of one reference document. Also, when NIST speaks of "the meter" it is usually (perhaps always) the utility meter. Just like any device, a utility meter can be an EMAN device. I don't think it helpful to put words into my mouth - I said nothing about the NIST definition of an ESI. My comment is internal to EMAN. Thanks, --Bruce On Mon, Jun 3, 2013 at 7:40 AM, Brad Schoening wrote: > Bruce, > > As NIST notes: > > "The meter and the energy service interface have very different > characteristics and functions. The logical separation of the meter and the > ESI is a very important forward-looking aspect of the reference model." > > I hope we all agree that aligning EMAN with existing standards is both > good and desirable. The above statement seems to be an absolutely clear > and reasonable explanation of why two topologies are helpful. It would > seem unwise to design an information model that was in conflict with recent > NIST standards. > > If you continue to feel that the NIST viewpoint is wrong, could you please > reference some other standards that would support your opinion. > > Regards, > > Brad > > On 6/3/2013 10:15 AM, Brad Schoening wrote: > > > *Brad Schoening* > Engineering | Coraid > Tel: +1 917 304 7190 > brads@coraid.com | www.coraid.com > *Coraid: Redefining Storage* > > > From: Bruce Nordman > Date: Sun, 2 Jun 2013 23:11:14 -0700 > To: "John Parello (jparello)" > Cc: eman mailing list , eman issue tracker < > trac+eman@trac.tools.ietf.org> > Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed > > Jon-- > > You brought aggregation to this discussion -- I did not do so and do > not see it as directly connected to powering/measurement. > > I am not sure what you see as missing from the requirements. > > You mention removing powering and metering topology modeling. > I never suggested this. I did observe that there is one topology > of power flows and so Powered-By and Metered-By address > the same issue so redundant to have both. We can > have a simpler structure which meets our needs which is > only good news > > Thanks, > > --Bruce > > > On Thu, May 30, 2013 at 3:32 PM, John Parello (jparello) < > jparello@cisco.com> wrote: > >> Hi Bruce, >> >> Yes, We are not chartered to specify coordination with the grid which >> would be a protocol. FSGIM (201p) from ashrae most certainly specifies >> information models not just for the grid but for facility devices as well >> so you are mistaken there. >> >> I think you confused protocol and information models again. >> >> We are chartered for models for device management and we would be amiss >> not to model information that ultimately would be used by EnMS' and grid >> coordination systems (load summaries) >> >> I find Brad's reference quite relevant. Both our existing taget EnMS >> users (with running code) and the quote he sites suggest imminent need for >> modeling relationships between devices for power and metering. >> >> Also we've recognized the need for power, metering and aggregation >> topologies prior to the draft of the requirements. So if your are citing >> that as missing from the requirements I think you've uncovered an error in >> the requirements not a justification for removing information models >> pertaining to relationships between devices. >> > >> Are you suggesting we remove power, metering, and aggregation topology >> modeling? >> > >> Jp >> >> Sent from my iPad >> (expect ridiculous spelling mistakes) >> >> On May 29, 2013, at 9:12 PM, "Bruce Nordman" wrote: >> >> I don't follow why the ESI would be relevant to EMAN. >> EMAN does not address coordination with the grid as >> many standards do. Standards designed for grid >> coordination (e.g. the FSGIM) have different purposes >> than EMAN and different fundamental models. The >> question at hand is what EMAN needs. >> --Bruce >> >> >> On Wed, May 29, 2013 at 6:38 AM, eman issue tracker < >> trac+eman@trac.tools.ietf.org> wrote: >> >>> #36: Consider whether MeteredBy relationship is needed >>> >>> >>> Comment (by brads@coraid.com): >>> >>> Other standards groups view !MeterBy and !PoweredBy as distinct logical >>> functions. For example, NIST Framework and Roadmap for Smart Grid >>> Interoperability Standards, Release 1.0 states: >>> >>> 3.5.1 Distinction between the Meter and the Energy Services Interface >>> >>> The meter and the ESI (Energy Services Interface) have very >>> different >>> characteristics and functions. The logical separation of the meter and >>> the >>> ESI is a very important forward-looking aspect of the reference model. >>> .. >>> While the ESI and meter are logically viewed as separate devices, >>> this >>> does not preclude the >>> possibility for manufacturers to implement the meter and ESI in one >>> physical device, provided >>> that the flexibility and extensibility to support the Smart Grid >>> vision can be achieved. Most smart >>> meters currently integrate the ESI and meter functionality in one >>> device due to cost >>> considerations. Looking forward, logical separation of the two >>> functions, even if physically >>> integrated, is essential to avoid having the meter become an >>> impediment to innovation in energy >>> services enabled by the Smart Grid." >>> >>> >>> Full Text here: >>> >>> http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf >>> >>> >>> -- >>> ------------------------------+-------------------- >>> Reporter: bnordman@lbl.gov | Owner: Bruce >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: framework | Version: >>> Severity: - | Resolution: >>> Keywords: | >>> ------------------------------+-------------------- >>> >>> Ticket URL: < >>> http://trac.tools.ietf.org/wg/eman/trac/ticket/36#comment:2> >>> >>> eman >>> >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>> >> >> >> >> -- >> *Bruce Nordman* >> Lawrence Berkeley National Laboratory >> *nordman.lbl.gov* >> BNordman@LBL.gov >> 510-486-7089 >> m: 510-501-7943 >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> >> > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov* > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > _______________________________________________ eman mailing list > eman@ietf.org https://www.ietf.org/mailman/listinfo/eman > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2904 / Virus Database: 3184/6356 - Release Date: 05/25/13 > Internal Virus Database is out of date. > > > > -- > *Brad Schoening* > Email: > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b10cccf04537204de43748e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

As a rem= inder, the issue tracker item in question is:
=A0 "#36: Consider wh= ether MeteredBy relationship is needed"
We have powered-by an= d metered-by is redundant.

Brad notes the Energy Services Interface concept from NIST, which=
page 41 of the reference he points notes:=A0 "... the Energy Servi= ces
Interface (ESI), which serves as the gateway to the Customer Premis= es Network. "
This the gateway from the Smart Grid (Utility).

My comme= nt had nothing to do with utility grids.
The requirements draft does not= include the words "smart"
or "grid" at all, and the= word "utility" only appears in the
name of one reference document.=A0 Also, when NIST speaks of
= "the meter" it is usually (perhaps always) the utility meter.
=
Just like any device, a utility meter can be an EMAN device.

I don't think it helpful to put words into my mout= h - I said nothing about
the NIST definition of an ESI.=A0 My comment is= internal to EMAN.

Thanks,

--Bruce



O= n Mon, Jun 3, 2013 at 7:40 AM, Brad Schoening <brad.schoening@ver= izon.net> wrote:
=20 =20 =20
Bruce,

As NIST notes:
"The meter and the energy service interface have ver= y different characteristics and functions. The logical separation of the meter and the ESI is a very important forward-looking aspect of the reference model."
I hope we all agree that aligning EMAN with existing standards is both good and desirable.=A0=A0 The above statement seems to be an absolutely clear and reasonable explanation of why two topologies are helpful.=A0 It would seem unwise to design an information model that was in conflict with recent NIST standards.

If you continue to feel that the NIST viewpoint is wrong, could you please reference some other standards that would support your opinion.=A0=A0

Regards,

Brad

On 6/3/2013 10:15 AM, Brad Schoening wrote:
=20

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@c= oraid.com | www.coraid.com
Coraid: Redefining Storage


From: Bruce Nordman <bnordma= n@lbl.gov>
Date: Sun, 2 Jun 2013 23:11:14 -0700
To: "John Parello (jparello)" <jparello@cisco.com>
Cc: eman mailing list <eman@ietf.= org>, eman issue tracker <trac+eman@trac.tools.ietf.org>
Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed

Jon--

You brought aggregation to this discussion -- I did not do so and do
not see it as directly connected to powering/measurement.

I am not sure what you see as missing from the requirements.

You mention removing powering and metering topology modeling.
I never suggested this.=A0 I did observe that there is one topology
of power flows and so Powered-By and Metered-By address
the same issue so redundant to have both.=A0 We can
have a simpler structure which meets our needs which is
only good news

Thanks,

--Bruce


On Thu, May 30, 2013 at 3:32 PM, John Parello (jparello) <jparello@cisco.com> wrote:
Hi Bruce,

Yes, We are not chartered to specify coordination with the grid which would be a protocol. FSGIM =A0(201p) from ashrae most certainly specifies information models not just for the grid but for facility devices as well so you are mistaken there.

I think you confused protocol and information models again.

We are chartered for models for device management and we would be amiss not to model information that ultimately would be used by EnMS' and grid coordination systems (load summaries)

=A0I find Brad's reference quite relevant. Both our existing taget EnMS users (with running code) and =A0the quote he sites suggest imminent need for modeling relationships between devices for power and metering.

Also we've recognized the need for power, metering and aggregation topologies prior to the draft of the requirements. So if your are citing that as missing from the requirements I think you've uncovered an error in the requirements not a justification for removing information models pertaining to relationships between devices.

Are you suggesting we remove power, metering, and aggregation topology modeling?

Jp

Sent from my iPad=A0
(expect ridiculous spelling mistakes)=A0

On May 29, 2013, at 9:12 PM, "Bruce Nordman&= quot; <bnordman@lbl.gov> wrote:

I don't follow why the ESI would be relevant to EMAN.
EMAN does not address coordination with the grid as
many standards do.=A0 Standards designed for grid
coordination (e.g. the FSGIM) have different purposes
than EMAN and different fundamental models.=A0 The
question at hand is what EMAN needs.
--Bruce


On Wed, May 29, 2013 at 6:38 AM, eman issue tracker <trac+eman@trac.tools.ietf.org>= wrote:
#36: Consider whether MeteredBy relationship is needed


Comment (by brads@coraid.com):

=A0Other standards groups view !MeterBy and !PoweredBy as distinct logical
=A0functions. =A0For example, NIST Framework and Roadmap for Smart Grid
=A0Interoperability Standards, Release 1.0 states:

=A03.5.1 Distinction between the Meter and the Energy Services Interface

=A0 =A0 =A0The meter and the ESI (Energy Services Interface) have very different
=A0characteristics and functions. The logical separation of the meter and the
=A0ESI is a very important forward-looking aspect of the reference model.
=A0 =A0 =A0..
=A0 =A0 =A0While the ESI and meter = are logically viewed as separate devices, this
=A0does not preclude the
=A0 =A0 =A0possibility for manufacturers to implement the meter and ESI in one
=A0physical device, provided
=A0 =A0 =A0that the flexibility and extensibility to support the Smart Grid
=A0vision can be achieved. Most smart
=A0 =A0 =A0meters currently integra= te the ESI and meter functionality in one
=A0device due to cost
=A0 =A0 =A0considerations. Looking forward, logical separation of the two
=A0functions, even if physically =A0 =A0 =A0integrated, is essential= to avoid having the meter become an =A0impediment to innovation in energy
=A0 =A0 =A0services enabled by the Smart Grid."


=A0Full Text here:
=A0http://www.nist.gov/public_affairs/releases/upload/smartgrid_in= teroperability_final.pdf


--
------------------------------+--------------------
=A0Reporter: =A0bnordman@lbl.gov =A0| =A0 =A0 =A0 Owner: =A0Bruc= e
=A0 =A0 =A0Type: =A0defect =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new<= br> =A0Priority: =A0major =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0framework =A0 =A0= =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 | =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
------------------------------+--------------------

Ticket URL: <http= ://trac.tools.ietf.org/wg/eman/trac/ticket/36#comment:2>

eman <http://tools.ietf.org/eman/>= ;

_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/li= stinfo/eman



--
Bruce Nordman=
La= wrence Berkeley National Laboratory=
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
____________________________________= ___________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/ema= n



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNo= rdman@LBL.gov
510-486-7089
m: 510-501-7943
_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman

No virus found in this message.
Checked by AVG - w= ww.avg.com
Version: 2013.0.2904 / Virus Database: 3184/6356 - Release Date: 05/25/13
Internal Virus Database is out of date.

<= font color=3D"#888888">


--
Brad Schoening
Email:



--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
nordman.lbl.gov=
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b10cccf04537204de43748e-- From jparello@cisco.com Mon Jun 3 10:58:18 2013 Return-Path: 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 9104021F859A for ; Mon, 3 Jun 2013 10:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.443 X-Spam-Level: X-Spam-Status: No, score=-7.443 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666] 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 4UvENTgvh2vW for ; Mon, 3 Jun 2013 10:58:05 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 72BEA21F85B8 for ; Mon, 3 Jun 2013 10:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17810; q=dns/txt; s=iport; t=1370282273; x=1371491873; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uB/8V+CNP8fmAKBhCPEENeSr+OSSxVBvhPtczxlmnEE=; b=EuNdu0O38sFDydt7ETAWkwAk77+zcfIp98ZNPmu870IcaZ6VIyOZSH7t njqJ7IsswMmtT9fYs7JArKBeuGkq3TQGT2t1B/O8d373gqKcda3D6gSSd VxReAUVvR3Vine8CcxqSOnjl8OHZx0UhH4Cmx9QwQkn/PaSGfAE3UKndk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAGnYrFGtJV2c/2dsb2JhbABWA4JFRDC2T4g2gQQWdIIkAQECAgEBAWsEBxACAQgOMQcnCxQRAgQOBRqHcwy8Fo12CYEYDAQGAQkIgmZhA5c+gSmKd4Uggw8 X-IronPort-AV: E=Sophos;i="4.87,794,1363132800"; d="scan'208,217";a="218260994" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jun 2013 17:57:53 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53HvqMl009850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 17:57:52 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.232]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 12:57:52 -0500 From: "John Parello (jparello)" To: Bruce Nordman Thread-Topic: [eman] #36: Consider whether MeteredBy relationship is needed Thread-Index: AQHOXHHi8LmspqWKJ0itWNPABefOsZkdcpuAgADfvUqABYrjAIAAcZ2V Date: Mon, 3 Jun 2013 17:57:52 +0000 Message-ID: <32ADE20B-7387-4A80-927A-C6F2B1DBA904@cisco.com> References: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> <070.6088bf1f90de3048ca60ae728c334000@trac.tools.ietf.org> <06C7C921-686A-466D-9ADE-6E0E1B4ED76D@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_32ADE20B73874A80927AC6F2B1DBA904ciscocom_" MIME-Version: 1.0 Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:58:18 -0000 --_000_32ADE20B73874A80927AC6F2B1DBA904ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruce, Ah ok, so The core of your premise it that you think powered by and metered= by are redundant. Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 that I= described 2) working systems that have this separated out and 3) the alig= nment with standard that recognize this that brad cited - I can't conclude = that they are redundant. You posited that they are redundant so the burden is yours to show that and= so far I don't see it. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jun 2, 2013, at 11:11 PM, "Bruce Nordman" > wrote: Jon-- You brought aggregation to this discussion -- I did not do so and do not see it as directly connected to powering/measurement. I am not sure what you see as missing from the requirements. You mention removing powering and metering topology modeling. I never suggested this. I did observe that there is one topology of power flows and so Powered-By and Metered-By address the same issue so redundant to have both. We can have a simpler structure which meets our needs which is only good news Thanks, --Bruce On Thu, May 30, 2013 at 3:32 PM, John Parello (jparello) > wrote: Hi Bruce, Yes, We are not chartered to specify coordination with the grid which would= be a protocol. FSGIM (201p) from ashrae most certainly specifies informat= ion models not just for the grid but for facility devices as well so you ar= e mistaken there. I think you confused protocol and information models again. We are chartered for models for device management and we would be amiss not= to model information that ultimately would be used by EnMS' and grid coord= ination systems (load summaries) I find Brad's reference quite relevant. Both our existing taget EnMS users= (with running code) and the quote he sites suggest imminent need for mode= ling relationships between devices for power and metering. Also we've recognized the need for power, metering and aggregation topologi= es prior to the draft of the requirements. So if your are citing that as mi= ssing from the requirements I think you've uncovered an error in the requir= ements not a justification for removing information models pertaining to re= lationships between devices. Are you suggesting we remove power, metering, and aggregation topology mode= ling? Jp Sent from my iPad (expect ridiculous spelling mistakes) On May 29, 2013, at 9:12 PM, "Bruce Nordman" > wrote: I don't follow why the ESI would be relevant to EMAN. EMAN does not address coordination with the grid as many standards do. Standards designed for grid coordination (e.g. the FSGIM) have different purposes than EMAN and different fundamental models. The question at hand is what EMAN needs. --Bruce On Wed, May 29, 2013 at 6:38 AM, eman issue tracker > wrote: #36: Consider whether MeteredBy relationship is needed Comment (by brads@coraid.com): Other standards groups view !MeterBy and !PoweredBy as distinct logical functions. For example, NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0 states: 3.5.1 Distinction between the Meter and the Energy Services Interface The meter and the ESI (Energy Services Interface) have very different characteristics and functions. The logical separation of the meter and the ESI is a very important forward-looking aspect of the reference model. .. While the ESI and meter are logically viewed as separate devices, this does not preclude the possibility for manufacturers to implement the meter and ESI in one physical device, provided that the flexibility and extensibility to support the Smart Grid vision can be achieved. Most smart meters currently integrate the ESI and meter functionality in one device due to cost considerations. Looking forward, logical separation of the two functions, even if physically integrated, is essential to avoid having the meter become an impediment to innovation in energy services enabled by the Smart Grid." Full Text here: http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperabil= ity_final.pdf -- ------------------------------+-------------------- Reporter: bnordman@lbl.gov | Owner: Bruc= e Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: Severity: - | Resolution: Keywords: | ------------------------------+-------------------- Ticket URL: eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_32ADE20B73874A80927AC6F2B1DBA904ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bruce,

Ah ok, so The core of your premise it that you think powered by and me= tered by are redundant.

Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 t= hat I described  2) working systems that have this separated out and 3= ) the alignment with standard that recognize this that brad cited - I can't= conclude that they are redundant. 

You posited that they are redundant so the burden is yours to show that and so far I don't see it.

Jp


Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jun 2, 2013, at 11:11 PM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

Jon--

You brought aggregation to this discussion -- I did not do so and do not see it as directly connected to powering/measurement.

I am not sure what you see as missing from the requirements.

You mention removing powering and metering topology modeling.
I never suggested this.  I did observe that there is one topology=
of power flows and so Powered-By and Metered-By address
the same issue so redundant to have both.  We can
have a simpler structure which meets our needs which is
only good news

Thanks,

--Bruce


On Thu, May 30, 2013 at 3:32 PM, John Parello (j= parello) <jparello@cisco.com> wrote:
Hi Bruce,

Yes, We are not chartered to specify coordination with the grid which = would be a protocol. FSGIM  (201p) from ashrae most certainly specifie= s information models not just for the grid but for facility devices as well= so you are mistaken there.

I think you confused protocol and information models again.

We are chartered for models for device management and we would be amis= s not to model information that ultimately would be used by EnMS' and grid = coordination systems (load summaries)

 I find Brad's reference quite relevant. Both our existing taget = EnMS users (with running code) and  the quote he sites suggest imminen= t need for modeling relationships between devices for power and metering.

Also we've recognized the need for power, metering and aggregation top= ologies prior to the draft of the requirements. So if your are citing that = as missing from the requirements I think you've uncovered an error in the r= equirements not a justification for removing information models pertaining to relationships between device= s.

Are you suggesting we remove power, metering, and aggregation topology= modeling?

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On May 29, 2013, at 9:12 PM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

I don't follow why the ESI would be relevant to EMAN.
EMAN does not address coordination with the grid as
many standards do.  Standards designed for grid
coordination (e.g. the FSGIM) have different purposes
than EMAN and different fundamental models.  The
question at hand is what EMAN needs.
--Bruce


On Wed, May 29, 2013 at 6:38 AM, eman issue tracker <= trac+eman@trac.tools.ietf.org> wrote:
#36: Consider whether MeteredBy relationship is needed


Comment (by brads@cor= aid.com):

 Other standards groups view !MeterBy and !PoweredBy as distinct logic= al
 functions.  For example, NIST Framework and Roadmap for Smart Gr= id
 Interoperability Standards, Release 1.0 states:

 3.5.1 Distinction between the Meter and the Energy Services Interface=

     The meter and the ESI (Energy Services Interface) have = very different
 characteristics and functions. The logical separation of the meter an= d the
 ESI is a very important forward-looking aspect of the reference model= .
     ..
     While the ESI and meter are logically viewed as separat= e devices, this
 does not preclude the
     possibility for manufacturers to implement the meter an= d ESI in one
 physical device, provided
     that the flexibility and extensibility to support the S= mart Grid
 vision can be achieved. Most smart
     meters currently integrate the ESI and meter functional= ity in one
 device due to cost
     considerations. Looking forward, logical separation of = the two
 functions, even if physically
     integrated, is essential to avoid having the meter beco= me an
 impediment to innovation in energy
     services enabled by the Smart Grid."


 Full Text here:
 http://www.nist.gov/public= _affairs/releases/upload/smartgrid_interoperability_final.pdf


--
------------------------------+--------------------
 Reporter:  bnordman@lbl.gov  |       Owner:  Bruce<= br>      Type:  defect           &= nbsp;|      Status:  new
 Priority:  major             | &nb= sp; Milestone:
Component:  framework         |     Vers= ion:
 Severity:  -             &nbs= p;   |  Resolution:
 Keywords:                 &nb= sp;  |
------------------------------+--------------------

Ticket URL: <http://trac.tools.ietf.org/wg/eman/trac/tick= et/36#comment:2>

eman <htt= p://tools.ietf.org/eman/>

_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 5= 10-486-7089
m: 510-501-7943
_______________________________________________
eman mailing list
eman@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--_000_32ADE20B73874A80927AC6F2B1DBA904ciscocom_-- From bnordman@lbl.gov Mon Jun 3 11:44:27 2013 Return-Path: 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 E405721F8616 for ; Mon, 3 Jun 2013 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=1.437, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Bc1gm+9KI7lm for ; Mon, 3 Jun 2013 11:44:07 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id C7EC421F8F78 for ; Mon, 3 Jun 2013 11:43:42 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwBAB/jrFHRVaAyk2dsb2JhbABWA4JFdLZRiDZ+CBYOAQEBAQcLCwkUBCSCIwEBBAFyBwULCws7IhIBBQEcBhMIAYd+BgyeP518jXUBgSEQBxGDRwOJII4egSmOMhYphFUcgTU X-IronPort-AV: E=Sophos;i="4.87,794,1363158000"; d="scan'208";a="19221491" Received: from mail-pb0-f50.google.com ([209.85.160.50]) by fe1.lbl.gov with ESMTP; 03 Jun 2013 11:43:42 -0700 Received: by mail-pb0-f50.google.com with SMTP id wy17so6118825pbc.37 for ; Mon, 03 Jun 2013 11:43:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=mL8IANfd0WApa2LjQReco2kALwg9leFEJ+4AT1Xy7vM=; b=VOQx71VUKSHTkaagpFYqjMl4Xhzl7maG5pk/LLLB2MtzDvGGDlRzGKGA4ed1SYmtI/ 6UATDnpLEbSgt2eZH2OaeB4z63JUP5mzx+NyyCmxiJ+/LG356XQC0vWsDawB9fiS7P9I tb/EQi5ErXmtBzMuPWfHNpdARDc7Muy5Bp09LZivIPuDDExlbh/wiekp9Bhwkmw2gxBp VP0gP7r8LTD3gpiwldDCu/GhbtqyIwQwa9dHz+swot4KaNrekz0Q1cqEumnANV2Q9Gc/ Ut6gpdytcrvyhZzeHP3vHqf9qFOIzTPrIgLuJQPw8TVJubAuljK3jiDA///ha3c6awyT q64w== X-Received: by 10.66.226.233 with SMTP id rv9mr25570222pac.155.1370285022213; Mon, 03 Jun 2013 11:43:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.226.233 with SMTP id rv9mr25570215pac.155.1370285022039; Mon, 03 Jun 2013 11:43:42 -0700 (PDT) Received: by 10.68.182.194 with HTTP; Mon, 3 Jun 2013 11:43:41 -0700 (PDT) In-Reply-To: <32ADE20B-7387-4A80-927A-C6F2B1DBA904@cisco.com> References: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> <070.6088bf1f90de3048ca60ae728c334000@trac.tools.ietf.org> <06C7C921-686A-466D-9ADE-6E0E1B4ED76D@cisco.com> <32ADE20B-7387-4A80-927A-C6F2B1DBA904@cisco.com> Date: Mon, 3 Jun 2013 11:43:41 -0700 Message-ID: From: Bruce Nordman To: "John Parello (jparello)" Content-Type: multipart/alternative; boundary=047d7b07245afade3904de445773 X-Gm-Message-State: ALoCoQmvktDpzmZSKw+eJLfHHSIhgI+hYF1hpp13rNew0gk6joSMdElRSQyGxiEzOB5QvzbZmbejReZKNGMZcUZr+upcrXfgMs0fpZYK7upH1g3ZiS4ISb27yBgtujvj2uOUvG+PWDEg Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:44:28 -0000 --047d7b07245afade3904de445773 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) wrote: > Hi Bruce, > > Ah ok, so The core of your premise it that you think powered by and > metered by are redundant. > Metered by is redundant to powered by, but I would not say the reverse is true, so step to solve this issue is to drop powered by. > > Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 > that I described 2) working systems that have this separated out and 3) > the alignment with standard that recognize this that brad cited - I can't > conclude that they are redundant. > We are definitely going in circles here. I addressed 1) in: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html and have reproduced the text from that below. I don't doubt 2), but that doesn't mean that doing so is something that EMAN needs to do or should do. For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html my comment has nothing to do with the NIST definitions or to the utility grid. Would you say that a device should be able to reference the utility meter that is ultimately upstream from it? Thanks, --Bruce ------------------------------------- My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html Specifying that the the dedicated meter functionality you describe is at a layer above the basic EMAN one of devices reporting about themselves or devices they are connected to is intriguing, and one I am quite sympathetic to, as a lot of system architectures these days lack a good sense of layering and so become overly complex. This approach to a meter seems to then be properly part of an Energy Management System that used EMAN and not part of the EMAN protocol itself. In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would suggest that any special EMAN content is needed. I do think it would be helpful to have a document describing EMS functions and how they use EMAN and what else they do. That seems like the right place for this dedicated meter proposal. It does seem clear that at the EMAN layer, the variety of energy objects that we have - devices, components, and power interfaces - are sufficient to fully implement it. Thanks, --Bruce > > You posited that they are redundant so the burden is yours to show that > and so far I don't see it. > > Jp > > > Sent from my iPad > (expect ridiculous spelling mistakes) > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b07245afade3904de445773 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) <jparel= lo@cisco.com> wrote:
Hi Bruce,

Ah ok, so The core of your premise it that you think powered by and me= tered by are redundant.
Metered by is redundan= t to powered by, but I would not say the reverse is true, so
step to solve this issue is to drop powered by.

Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 t= hat I described =A02) working systems that have this separated out and 3) t= he alignment with standard that recognize this that brad cited - I can'= t conclude that they are redundant.=A0

We are definitely going in circles h= ere.
and have reproduced the text from that below.
I do= n't doubt 2), but that doesn't mean that doing so is something that= EMAN
needs to do or should do.
For 3), per my response a = few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg0= 1882.html
my comment has nothing to do with the NIST definitions or to the= utility grid.

Would you say that a device should be able= to reference the utility meter that
is ultimately upstream f= rom it?

Thanks,

--Bruce
------------= -------------------------
My text from: http://www.ietf.org/mail= -archive/web/eman/current/msg01871.html
=A0
Specifying that the t= he dedicated meter functionality you describe
is at a layer above the ba= sic EMAN one of devices reporting about
themselves or devices they are c= onnected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
l= ack a good sense of layering and so become overly complex.=A0

This approach to a meter seems to then be properly part of an Energy
Management System that used EMAN and not part of the EMAN
protocol itse= lf.

In re-reviewing the Requirements document, I can't fin= d reference to
dedicated meters as are being described here in a way th= at would
suggest that any special EMAN content is needed.=A0 I do think it would be<= br>helpful to have a document describing EMS functions and how they
use = EMAN and what else they do.=A0 That seems like the right place
for this = dedicated meter proposal.

It does seem clear that at the EMAN layer, the variety of energy<= br>objects that we have - devices, components, and power interfaces -
ar= e sufficient to fully implement it.=A0

Thanks,

--Bruce
<= div bgcolor=3D"#FFFFFF">

You posited that they are redundant so the burden is yours to show that and so far I don't see it.<= /div>

Jp


Sent from my iPad=A0
(expect ridiculous spelling mistakes)=A0


--
Bruce Nordman
Lawrenc= e Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b07245afade3904de445773-- From brads@coraid.com Mon Jun 3 12:36:09 2013 Return-Path: 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 063B421E80E7 for ; Mon, 3 Jun 2013 12:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dX5ODM6+kcvu for ; Mon, 3 Jun 2013 12:35:55 -0700 (PDT) Received: from server506.appriver.com (server506b.appriver.com [50.56.144.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97521E80A0 for ; Mon, 3 Jun 2013 12:29:40 -0700 (PDT) X-Note-AR-ScanTimeLocal: 6/3/2013 2:29:39 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com 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->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G319 G320 G321 G322 G326 G327 G338 G434 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 85034124; Mon, 03 Jun 2013 14:29:39 -0500 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.110]) by HT05-E6.exg6.exghost.com ([10.242.230.112]) with mapi id 14.03.0123.003; Mon, 3 Jun 2013 14:29:35 -0500 From: Brad Schoening To: Bruce Nordman , "John Parello (jparello)" Thread-Topic: [eman] #36: Consider whether MeteredBy relationship is needed Thread-Index: AQHOXHHhzh/O4jKbnUi4E5r48K8lqZkdcpuAgAEzjgCABTcSAIAAxW4AgAAMzYD//8nDgA== Date: Mon, 3 Jun 2013 19:29:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.247] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_CDD25DD2AE72Cbradscoraidcom_" MIME-Version: 1.0 Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:36:09 -0000 --_000_CDD25DD2AE72Cbradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BN: Would you say that a device should be able to reference the utility met= er that is ultimately upstream from it? Yes, absolutely. We did exactly that at Noveda. Consider the following: Building Smart Meter ----> Raritan Smart PDU (but no metering) ---> Cis= co Switch #1) How would you use MeteredBy for the PDU which doesn't have a meter? Ci= scoSwitch Powered-by RaritanPDU seems necessary. #2) Do you believe "utility meters" are functionally different from "smart = sub-meters"? I'm not sure I see any distinction. From: Bruce Nordman > Date: Mon, 3 Jun 2013 11:43:41 -0700 To: "John Parello (jparello)" > Cc: eman mailing list >, eman issue tra= cker > Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) > wrote: Hi Bruce, Ah ok, so The core of your premise it that you think powered by and metered= by are redundant. Metered by is redundant to powered by, but I would not say the reverse is t= rue, so step to solve this issue is to drop powered by. Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 that I= described 2) working systems that have this separated out and 3) the alig= nment with standard that recognize this that brad cited - I can't conclude = that they are redundant. We are definitely going in circles here. I addressed 1) in: http://www.ietf.org/mail-archive/web/eman/current/msg01= 871.html and have reproduced the text from that below. I don't doubt 2), but that doesn't mean that doing so is something that EMA= N needs to do or should do. For 3), per my response a few minutes ago at: http://www.ietf.org/mail-arch= ive/web/eman/current/msg01882.html my comment has nothing to do with the NIST definitions or to the utility gr= id. Would you say that a device should be able to reference the utility meter t= hat is ultimately upstream from it? Thanks, --Bruce ------------------------------------- My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.ht= ml Specifying that the the dedicated meter functionality you describe is at a layer above the basic EMAN one of devices reporting about themselves or devices they are connected to is intriguing, and one I am quite sympathetic to, as a lot of system architectures these days lack a good sense of layering and so become overly complex. This approach to a meter seems to then be properly part of an Energy Management System that used EMAN and not part of the EMAN protocol itself. In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would suggest that any special EMAN content is needed. I do think it would be helpful to have a document describing EMS functions and how they use EMAN and what else they do. That seems like the right place for this dedicated meter proposal. It does seem clear that at the EMAN layer, the variety of energy objects that we have - devices, components, and power interfaces - are sufficient to fully implement it. Thanks, --Bruce You posited that they are redundant so the burden is yours to show that and= so far I don't see it. Jp Sent from my iPad (expect ridiculous spelling mistakes) -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CDD25DD2AE72Cbradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <79077A7DC1B61849B6B3A6759EAB4161@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable
BN: Would you say that a device should be able to reference the utilit= y meter that
is ultimately upstream from it?

Yes, absolutely.  We did exactly that at Noveda.

Consider the following:

Buildi= ng Smart Meter  ---->  Raritan Smart PDU (but no metering) &nb= sp;--->  Cisco Switch

#1) How would you use MeteredBy for the PDU which doesn't have a meter= ?  CiscoSwitch Powered-by RaritanPDU seems necessary.
#2) Do you believe "utility meters" are functionally differe= nt from "smart sub-meters"?  I'm not sure I see any distinct= ion.

From: Bruce Nordman <bnordman@lbl.gov>
Date: Mon, 3 Jun 2013 11:43:41 -070= 0
To: "John Parello (jparello)&q= uot; <jparello@cisco.com> Cc: eman mailing list <eman@ietf.org>, eman issue tracker <trac+eman@trac.tools.= ietf.org>
Subject: Re: [eman] #36: Consider w= hether MeteredBy relationship is needed




On Mon, Jun 3, 2013 at 10:57 AM, John Parello (j= parello) <jparello@cisco.com> wrote:
Hi Bruce,

Ah ok, so The core of your premise it that you think powered by and me= tered by are redundant.
Metered by is redundant to powered by, but I would not say the reverse= is true, so
step to solve this issue is to drop powered by.

Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 t= hat I described  2) working systems that have this separated out and 3= ) the alignment with standard that recognize this that brad cited - I can't= conclude that they are redundant. 

We are definitely going in circles here.
and have reproduced the text from that below.
I don't doubt 2), but that doesn't mean that doing so is something tha= t EMAN
needs to do or should do.
For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html
my comment has nothing to do with the NIST definitions or to the utili= ty grid.

Would you say that a device should be able to reference the utility me= ter that
is ultimately upstream from it?

Thanks,

--Bruce
-------------------------------------
My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html
 
Specifying that the the dedicated meter functionality you describe
is at a layer above the basic EMAN one of devices reporting about
themselves or devices they are connected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
lack a good sense of layering and so become overly complex. 

This approach to a meter seems to then be properly part of an Energy
Management System that used EMAN and not part of the EMAN
protocol itself.

In re-reviewing the Requirements document, I can't find reference to
dedicated meters as are being described here in a way that would
suggest that any special EMAN content is needed.  I do think it would = be
helpful to have a document describing EMS functions and how they
use EMAN and what else they do.  That seems like the right place
for this dedicated meter proposal.

It does seem clear that at the EMAN layer, the variety of energy
objects that we have - devices, components, and power interfaces -
are sufficient to fully implement it. 

Thanks,

--Bruce

You posited that they are redundant so the burden is yours to sh= ow that and so far I don't see it.

Jp


Sent from my iPad 
(expect ridiculous spelling mistakes) 


--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
_______________________________________________ eman mailing list eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman --_000_CDD25DD2AE72Cbradscoraidcom_-- From jparello@cisco.com Mon Jun 3 15:40:43 2013 Return-Path: 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 3894621F909A for ; Mon, 3 Jun 2013 15:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 eRgzAStq4BbV for ; Mon, 3 Jun 2013 15:40:29 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 03DD511E80A5 for ; Mon, 3 Jun 2013 15:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9137; q=dns/txt; s=iport; t=1370298972; x=1371508572; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gFNOjgcup2rrE52LFY7GSiwCLKHPkugC++8zRnP+TgM=; b=RD7kXU091xSKRag/PBj9SDmkADjQ9Jfoa8lmea4Zl6wB6hCer5t0O6l2 srGHyUX9Wo2mbx6LENQKqc+xMjaV5Ldo1fRbQlYmKip5S1tyVuabLuSBC asP+FvM/LatTqG4vRurDTDp/4vhBQmcoH1BbhmUGhnZT5BQMu2HdalH38 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAK0ZrVGtJXHA/2dsb2JhbABWA4JFRDC2Uog2gQgWdIIkAQEEcgcQAgEIDjEHMhQRAgQOBQmIBAy8UI11AYEhEAYBCQiCZmEDk22DUYEpkBeDD4Fx X-IronPort-AV: E=Sophos;i="4.87,795,1363132800"; d="scan'208,217";a="218313206" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 03 Jun 2013 22:36:11 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53MaBYG016353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 22:36:11 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.232]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 17:36:10 -0500 From: "John Parello (jparello)" To: Bruce Nordman Thread-Topic: [eman] #36: Consider whether MeteredBy relationship is needed Thread-Index: AQHOXHHi8LmspqWKJ0itWNPABefOsZkdcpuAgADfvUqABYrjAIAAcZ2VgABgnoD//+0knA== Date: Mon, 3 Jun 2013 22:36:10 +0000 Message-ID: <75701DE1-E567-4121-9A19-CEE81FF6C603@cisco.com> References: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> <070.6088bf1f90de3048ca60ae728c334000@trac.tools.ietf.org> <06C7C921-686A-466D-9ADE-6E0E1B4ED76D@cisco.com> <32ADE20B-7387-4A80-927A-C6F2B1DBA904@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_75701DE1E56741219A19CEE81FF6C603ciscocom_" MIME-Version: 1.0 Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:40:43 -0000 --_000_75701DE1E56741219A19CEE81FF6C603ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruce, Definitely not going in circles. I considered it and I don't agree the rela= tionships are redundant in any order for the reasons I outlined. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jun 3, 2013, at 11:43 AM, "Bruce Nordman" > wrote: On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) > wrote: Hi Bruce, Ah ok, so The core of your premise it that you think powered by and metered= by are redundant. Metered by is redundant to powered by, but I would not say the reverse is t= rue, so step to solve this issue is to drop powered by. Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 that I= described 2) working systems that have this separated out and 3) the alig= nment with standard that recognize this that brad cited - I can't conclude = that they are redundant. We are definitely going in circles here. I addressed 1) in: http://www.ietf.org/mail-archive/web/eman/current/msg01= 871.html and have reproduced the text from that below. I don't doubt 2), but that doesn't mean that doing so is something that EMA= N needs to do or should do. For 3), per my response a few minutes ago at: http://www.ietf.org/mail-arch= ive/web/eman/current/msg01882.html my comment has nothing to do with the NIST definitions or to the utility gr= id. Would you say that a device should be able to reference the utility meter t= hat is ultimately upstream from it? Thanks, --Bruce ------------------------------------- My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.ht= ml Specifying that the the dedicated meter functionality you describe is at a layer above the basic EMAN one of devices reporting about themselves or devices they are connected to is intriguing, and one I am quite sympathetic to, as a lot of system architectures these days lack a good sense of layering and so become overly complex. This approach to a meter seems to then be properly part of an Energy Management System that used EMAN and not part of the EMAN protocol itself. In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would suggest that any special EMAN content is needed. I do think it would be helpful to have a document describing EMS functions and how they use EMAN and what else they do. That seems like the right place for this dedicated meter proposal. It does seem clear that at the EMAN layer, the variety of energy objects that we have - devices, components, and power interfaces - are sufficient to fully implement it. Thanks, --Bruce You posited that they are redundant so the burden is yours to show that and= so far I don't see it. Jp Sent from my iPad (expect ridiculous spelling mistakes) -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_75701DE1E56741219A19CEE81FF6C603ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bruce,

Definitely not going in circles. I considered it and I don't agree the= relationships are redundant in any order for the reasons I outlined. =

Jp


Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jun 3, 2013, at 11:43 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:




On Mon, Jun 3, 2013 at 10:57 AM, John Parello (j= parello) <jparello@cisco.com> wrote:
Hi Bruce,

Ah ok, so The core of your premise it that you think powered by and me= tered by are redundant.
Metered by is redundant to powered by, but I would not say the reverse= is true, so
step to solve this issue is to drop powered by.

Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 t= hat I described  2) working systems that have this separated out and 3= ) the alignment with standard that recognize this that brad cited - I can't= conclude that they are redundant. 

We are definitely going in circles here.
and have reproduced the text from that below.
I don't doubt 2), but that doesn't mean that doing so is something tha= t EMAN
needs to do or should do.
For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html
my comment has nothing to do with the NIST definitions or to the utili= ty grid.

Would you say that a device should be able to reference the utility me= ter that
is ultimately upstream from it?

Thanks,

--Bruce
-------------------------------------
My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html
 
Specifying that the the dedicated meter functionality you describe
is at a layer above the basic EMAN one of devices reporting about
themselves or devices they are connected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
lack a good sense of layering and so become overly complex. 

This approach to a meter seems to then be properly part of an Energy
Management System that used EMAN and not part of the EMAN
protocol itself.

In re-reviewing the Requirements document, I can't find reference to
dedicated meters as are being described here in a way that would
suggest that any special EMAN content is needed.  I do think it would = be
helpful to have a document describing EMS functions and how they
use EMAN and what else they do.  That seems like the right place
for this dedicated meter proposal.

It does seem clear that at the EMAN layer, the variety of energy
objects that we have - devices, components, and power interfaces -
are sufficient to fully implement it. 

Thanks,

--Bruce

You posited that they are redundant so the burden is yours to sh= ow that and so far I don't see it.

Jp


Sent from my iPad 
(expect ridiculous spelling mistakes) 


--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--_000_75701DE1E56741219A19CEE81FF6C603ciscocom_-- From karagian@cs.utwente.nl Tue Jun 4 04:04:26 2013 Return-Path: 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 A150E21F9CF3 for ; Tue, 4 Jun 2013 04:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 lNh2+eyWx+Pc for ; Tue, 4 Jun 2013 04:03:52 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8E21F9B3B for ; Tue, 4 Jun 2013 02:57:04 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 4 Jun 2013 11:57:04 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.91]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 11:57:04 +0200 From: To: , Thread-Topic: [eman] #36: Consider whether MeteredBy relationship is needed Thread-Index: AQHOXHHjge9IPKt8v0mxDtsrdlb1E5kc/UKAgAEzjgCABTcSAIAAxW4AgAAMzoCAAED0AIAA3XzA Date: Tue, 4 Jun 2013 09:57:03 +0000 Message-ID: References: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> <070.6088bf1f90de3048ca60ae728c334000@trac.tools.ietf.org> <06C7C921-686A-466D-9ADE-6E0E1B4ED76D@cisco.com> <32ADE20B-7387-4A80-927A-C6F2B1DBA904@cisco.com>, <75701DE1-E567-4121-9A19-CEE81FF6C603@cisco.com> In-Reply-To: <75701DE1-E567-4121-9A19-CEE81FF6C603@cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F393E8AEXMBX23adutwent_" MIME-Version: 1.0 Cc: eman@ietf.org, trac+eman@grenache.tools.ietf.org Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 11:04:27 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F393E8AEXMBX23adutwent_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I agree with John, the MeteredBy relationship is needed for the support of = several scenarios, see e.g., "Home energy gateways" scenario in section 2= .7 of: http://www.ietf.org/id/draft-ietf-eman-applicability-statement-03.txt Best regards, Georgios From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Joh= n Parello (jparello) Sent: dinsdag 4 juni 2013 0:36 To: Bruce Nordman Cc: eman mailing list; eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed Hi Bruce, Definitely not going in circles. I considered it and I don't agree the rela= tionships are redundant in any order for the reasons I outlined. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jun 3, 2013, at 11:43 AM, "Bruce Nordman" > wrote: On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) > wrote: Hi Bruce, Ah ok, so The core of your premise it that you think powered by and metered= by are redundant. Metered by is redundant to powered by, but I would not say the reverse is t= rue, so step to solve this issue is to drop powered by. Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 that I= described 2) working systems that have this separated out and 3) the alig= nment with standard that recognize this that brad cited - I can't conclude = that they are redundant. We are definitely going in circles here. I addressed 1) in: http://www.ietf.org/mail-archive/web/eman/current/msg01= 871.html and have reproduced the text from that below. I don't doubt 2), but that doesn't mean that doing so is something that EMA= N needs to do or should do. For 3), per my response a few minutes ago at: http://www.ietf.org/mail-arch= ive/web/eman/current/msg01882.html my comment has nothing to do with the NIST definitions or to the utility gr= id. Would you say that a device should be able to reference the utility meter t= hat is ultimately upstream from it? Thanks, --Bruce ------------------------------------- My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.ht= ml Specifying that the the dedicated meter functionality you describe is at a layer above the basic EMAN one of devices reporting about themselves or devices they are connected to is intriguing, and one I am quite sympathetic to, as a lot of system architectures these days lack a good sense of layering and so become overly complex. This approach to a meter seems to then be properly part of an Energy Management System that used EMAN and not part of the EMAN protocol itself. In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would suggest that any special EMAN content is needed. I do think it would be helpful to have a document describing EMS functions and how they use EMAN and what else they do. That seems like the right place for this dedicated meter proposal. It does seem clear that at the EMAN layer, the variety of energy objects that we have - devices, components, and power interfaces - are sufficient to fully implement it. Thanks, --Bruce You posited that they are redundant so the burden is yours to show that and= so far I don't see it. Jp Sent from my iPad (expect ridiculous spelling mistakes) -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F393E8AEXMBX23adutwent_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

 <= /p>

I agree wi= th John, the MeteredBy relationship is needed for the support of several sc= enarios, see e.g.,   “Home energy gateways” scenario = in section 2.7 of:

htt= p://www.ietf.org/id/draft-ietf-eman-applicability-statement-03.txt=

 = ;

Best regar= ds,

Georgios

 = ;

 = ;

 = ;

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello)
Sent: dinsdag 4 juni 2013 0:36
To: Bruce Nordman
Cc: eman mailing list; eman issue tracker
Subject: Re: [eman] #36: Consider whether MeteredBy relationship is = needed

 

Hi Bruce,

 

Definitely not going in circles. I considered it and= I don't agree the relationships are redundant in any order for the reasons= I outlined. 

 

Jp

 

 

Sent from my iPad 

(expect ridiculous spelling mistakes) 


On Jun 3, 2013, at 11:43 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

 

 

On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jpare= llo) <jparello@c= isco.com> wrote:

Hi Bruce,

 

Ah ok, so The core of your premise it that you think= powered by and metered by are redundant.

Metered by is redundant to powered by, but I would n= ot say the reverse is true, so

step to solve this issue is to drop powered by.=

 

Given 1) the analogyy in modeling indescribes to lay= er-2 and layer-3 that I described  2) working systems that have this s= eparated out and 3) the alignment with standard that recognize this that br= ad cited - I can't conclude that they are redundant. 

 

We are definitely going in circles here.<= /p>

and have reproduced the text from that below.

I don't doubt 2), but that doesn't mean that doing s= o is something that EMAN
needs to do or should do.

For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html

my comment has nothin= g to do with the NIST definitions or to the utility grid.

Would you say that a device should be able to refere= nce the utility meter that

is ultimately upstream from it?

 

Thanks,

--Bruce
-------------------------------------

My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html
 

Specifying that the t= he dedicated meter functionality you describe
is at a layer above the basic EMAN one of devices reporting about
themselves or devices they are connected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
lack a good sense of layering and so become overly complex. 

This approach to a meter seems to then be properly p= art of an Energy
Management System that used EMAN and not part of the EMAN
protocol itself.


In re-reviewing the Requirements document, I can't find reference to
dedicated meters as are being described here in a way that would
suggest that any special EMAN content is needed.  I do think it would = be
helpful to have a document describing EMS functions and how they
use EMAN and what else they do.  That seems like the right place
for this dedicated meter proposal.

It does seem clear th= at at the EMAN layer, the variety of energy
objects that we have - devices, components, and power interfaces -
are sufficient to fully implement it. 

Thanks,

 

--Bruce

 

You posited that they are redundant so the burden is= yours to show that and so far I don't see it.

 

Jp

 


Sent from my iPad 

(expect ridiculous spelling mistakes) 



--
Bruce Nordman
Lawrence Berkeley National Laboratory<= br> nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F393E8AEXMBX23adutwent_-- From iesg-secretary@ietf.org Tue Jun 4 09:11:30 2013 Return-Path: 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 47BD521E80CE; Tue, 4 Jun 2013 09:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 F5g9tlNR+c9Y; Tue, 4 Jun 2013 09:11:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 429BF21F9B8C; Tue, 4 Jun 2013 07:01:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130604140119.27892.78840.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 07:01:19 -0700 Cc: eman mailing list , eman chair , RFC Editor Subject: [eman] Document Action: 'Requirements for Energy Management' to Informational RFC (draft-ietf-eman-requirements-14.txt) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:11:30 -0000 The IESG has approved the following document: - 'Requirements for Energy Management' (draft-ietf-eman-requirements-14.txt) as Informational RFC This document is the product of the Energy Management Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/ Technical Summary: This document defines requirements for standards specifications for energy management. These concern monitoring functions as well as control functions: Monitoring functions include identification of energy-managed devices and their components, monitoring of their power states, power inlets, power outlets, actual power, power properties, received energy, provided energy, and contained batteries. Control functions serve for controlling power supply and power state of energy-managed devices and their components. Working Group Summary: Version -08 of this draft was presented in the EMAN session at IETF 84 (Vancouver). The authors published -09, resolving the open issues discussed at that meeting. The draft's Working Group Last Call ran from 4 October to 22 October this year, and raised several more issues. After IETF-85, the authors published its -10 version; we believe it is now ready to submit to IESG. Document Quality: Are there existing implementations of the protocol? This is a requirements draft, not a protocol. Have a significant number of vendors indicated their plan to implement the specification? At least two vendors have implemented Energy Management systems, and - presumably - will make them EMAN-compliant. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Since September the following have contributed comments on the EMAN list: Ira McDonald, John Parello, Brad Schoening, Georgios Karagian. However, the draft's authors/editors have done most of the work in developing it. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? The draft hasn't had any kind of expert review. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Nevil Brownlee Area Director: Joel Jaeggli From brads@coraid.com Tue Jun 4 14:35:19 2013 Return-Path: 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 7DE5821F8EB2 for ; Tue, 4 Jun 2013 14:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 iyoD2JwEOJHi for ; Tue, 4 Jun 2013 14:35:15 -0700 (PDT) Received: from server506.appriver.com (server506b.appriver.com [50.56.144.14]) by ietfa.amsl.com (Postfix) with ESMTP id D3BC221F9C03 for ; Tue, 4 Jun 2013 14:08:22 -0700 (PDT) X-Note-AR-ScanTimeLocal: 6/4/2013 4:08:22 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com 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->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G319 G320 G321 G322 G326 G327 G338 G434 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 85606875; Tue, 04 Jun 2013 16:08:22 -0500 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.110]) by HT02-E6.exg6.exghost.com ([50.56.144.20]) with mapi id 14.03.0123.003; Tue, 4 Jun 2013 16:08:20 -0500 From: Brad Schoening To: Bruce Nordman Thread-Topic: [eman] #36: Consider whether MeteredBy relationship is needed Thread-Index: AQHOXHHhzh/O4jKbnUi4E5r48K8lqZkdcpuAgAEzjgCABTcSAIAAxW4AgAAMzYD//8nDgIAB52aA///GgwA= Date: Tue, 4 Jun 2013 21:08:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.247] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_CDD3CDFBB012Ebradscoraidcom_" MIME-Version: 1.0 Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:35:19 -0000 --_000_CDD3CDFBB012Ebradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruce, I'm not sure I understand which relationship you are suggesting is redundan= t. Below you use the PowerBy relationship, while on Monday, you stated "so= step to solve this issue is to drop powered by." Regards, Brad Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Bruce Nordman > Date: Tue, 4 Jun 2013 13:34:01 -0700 To: Brad Schoening > Cc: "John Parello (jparello)" >, eman mailing list >, eman issue tra= cker > Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed < A few minutes ago I sent a blank reply by accident; apologies > For referencing the utility meter, we have the Domain part of the EMAN Fram= ework, which notes that it is "... recommended to map 1:1 with a metered or sub-me= tered portion of the site." Problem solved. My comment did not question the inclusion of Domain. #1. For the Building-meter -> PDU -> Switch case, the Switch is Powered-by = the PDU and the PDU is Powered-by the Building-meter. Plus, both specify that they are in the = Domain of the Building-meter, so we have double referencing to the utility meter even wit= hout the Metered-by concept. #2. I agree with you that for EMAN there is no functional difference betwee= n a utility meter and a sub-meter. Furthermore, any meter is just a device in the EMAN= context. It is a device with metering as its primary function but not different for = EMAN purposes. Thanks, --Bruce On Mon, Jun 3, 2013 at 12:29 PM, Brad Schoening > wrote: BN: Would you say that a device should be able to reference the utility met= er that is ultimately upstream from it? Yes, absolutely. We did exactly that at Noveda. Consider the following: Building Smart Meter ----> Raritan Smart PDU (but no metering) ---> Cis= co Switch #1) How would you use MeteredBy for the PDU which doesn't have a meter? Ci= scoSwitch Powered-by RaritanPDU seems necessary. #2) Do you believe "utility meters" are functionally different from "smart = sub-meters"? I'm not sure I see any distinction. From: Bruce Nordman > Date: Mon, 3 Jun 2013 11:43:41 -0700 To: "John Parello (jparello)" > Cc: eman mailing list >, eman issue tra= cker > Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) > wrote: Hi Bruce, Ah ok, so The core of your premise it that you think powered by and metered= by are redundant. Metered by is redundant to powered by, but I would not say the reverse is t= rue, so step to solve this issue is to drop powered by. Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 that I= described 2) working systems that have this separated out and 3) the alig= nment with standard that recognize this that brad cited - I can't conclude = that they are redundant. We are definitely going in circles here. I addressed 1) in: http://www.ietf.org/mail-archive/web/eman/current/msg01= 871.html and have reproduced the text from that below. I don't doubt 2), but that doesn't mean that doing so is something that EMA= N needs to do or should do. For 3), per my response a few minutes ago at: http://www.ietf.org/mail-arch= ive/web/eman/current/msg01882.html my comment has nothing to do with the NIST definitions or to the utility gr= id. Would you say that a device should be able to reference the utility meter t= hat is ultimately upstream from it? Thanks, --Bruce ------------------------------------- My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.ht= ml Specifying that the the dedicated meter functionality you describe is at a layer above the basic EMAN one of devices reporting about themselves or devices they are connected to is intriguing, and one I am quite sympathetic to, as a lot of system architectures these days lack a good sense of layering and so become overly complex. This approach to a meter seems to then be properly part of an Energy Management System that used EMAN and not part of the EMAN protocol itself. In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would suggest that any special EMAN content is needed. I do think it would be helpful to have a document describing EMS functions and how they use EMAN and what else they do. That seems like the right place for this dedicated meter proposal. It does seem clear that at the EMAN layer, the variety of energy objects that we have - devices, components, and power interfaces - are sufficient to fully implement it. Thanks, --Bruce You posited that they are redundant so the burden is yours to show that and= so far I don't see it. Jp Sent from my iPad (expect ridiculous spelling mistakes) -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_CDD3CDFBB012Ebradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Bruce,

I'm not sure I understand which relationship you are suggesting is red= undant.  Below you use the PowerBy relationship, while on Monday, you = stated "so step to solve this issue is to drop powered by." =  

Regards,

Brad

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
Coraid: Redefinin= g Storage


From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 4 Jun 2013 13:34:01 -070= 0
To: Brad Schoening <brads@coraid.com>
Cc: "John Parello (jparello)&q= uot; <jparello@cisco.com>, = eman mailing list <eman@ietf.org>= ;, eman issue tracker <trac+eman@trac.tools.ietf.org>
Subject: Re: [eman] #36: Consider w= hether MeteredBy relationship is needed

< A few minutes ago I sent a blank reply by accident; apologies = >


For referencing the utility meter, we have the Domain part of the EMAN Fram= ework,
which notes that it is "... recommended to map 1:1 with a metered= or sub-metered portion of the site."
Problem solved.  My comment did not question the inclusion of Domain.<= br>
#1. For the Building-meter -> PDU -> Switch case, the Switch is Power= ed-by the PDU and the PDU
is Powered-by the Building-meter.  Plus, both specify that they are in= the Domain of the
Building-meter, so we have double referencing to the utility meter even wit= hout the Metered-by
concept.

#2. I agree with you that for EMAN there is no functional difference betwee= n a utility
meter and a sub-meter.  Furthermore, any meter is just a device in the= EMAN context.
It is a device with metering as its primary function but not different for = EMAN purposes.

Thanks,

--Bruce

#1) How would you use MeteredBy for the PDU which doesn't have a meter= ?  CiscoSwitch Powered-by RaritanPDU seems necessary.
#2) Do you believe "utility meters" are functionally differe= nt from "smart sub-meters"?  I'm not sure I see any distinct= ion.

From: Bruce Nordman <bnordman@lbl.gov>
Date: Mon, 3 Jun 2013 11:43:41 -070= 0

To: "John Parello (jparello)&q= uot; <jparello@c= isco.com>
Cc: eman mailing list <eman@ietf.org>, eman iss= ue tracker <trac+eman@trac.tools.ietf.org>
Subject: Re: [eman] #36: Consider w= hether MeteredBy relationship is needed




On Mon, Jun 3, 2013 at 10:57 AM, John Parello (j= parello) <jparello@cisco.com> wrote:
Hi Bruce,

Ah ok, so The core of your premise it that you think powered by and me= tered by are redundant.
Metered by is redundant to powered by, but I would not say the reverse= is true, so
step to solve this issue is to drop powered by.

Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 t= hat I described  2) working systems that have this separated out and 3= ) the alignment with standard that recognize this that brad cited - I can't= conclude that they are redundant. 

We are definitely going in circles here.
and have reproduced the text from that below.
I don't doubt 2), but that doesn't mean that doing so is something tha= t EMAN
needs to do or should do.
For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html
my comment has nothing to do with the NIST definitions or to the utili= ty grid.

Would you say that a device should be able to reference the utility me= ter that
is ultimately upstream from it?

Thanks,

--Bruce
-------------------------------------
My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html
 
Specifying that the the dedicated meter functionality you describe
is at a layer above the basic EMAN one of devices reporting about
themselves or devices they are connected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
lack a good sense of layering and so become overly complex. 

This approach to a meter seems to then be properly part of an Energy
Management System that used EMAN and not part of the EMAN
protocol itself.

In re-reviewing the Requirements document, I can't find reference to
dedicated meters as are being described here in a way that would
suggest that any special EMAN content is needed.  I do think it would = be
helpful to have a document describing EMS functions and how they
use EMAN and what else they do.  That seems like the right place
for this dedicated meter proposal.

It does seem clear that at the EMAN layer, the variety of energy
objects that we have - devices, components, and power interfaces -
are sufficient to fully implement it. 

Thanks,

--Bruce

You posited that they are redundant so the burden is yours to sh= ow that and so far I don't see it.

Jp


Sent from my iPad 
(expect ridiculous spelling mistakes) 


--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 5= 10-486-7089
m: 510-501-7943
_______________________________________________ eman mail= ing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--_000_CDD3CDFBB012Ebradscoraidcom_-- From bnordman@lbl.gov Tue Jun 4 14:38:09 2013 Return-Path: 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 C854121F99BA for ; Tue, 4 Jun 2013 14:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 3uqv4uPJlqG0 for ; Tue, 4 Jun 2013 14:38:05 -0700 (PDT) Received: from fe2.lbl.gov (fe2.lbl.gov [128.3.41.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0B15E21F9AB7 for ; Tue, 4 Jun 2013 13:34:02 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAAJNOrlHRVcCxm2dsb2JhbABXA4JFdLZkiEVzCBYOAQEBAQEGCwsJFCiCIwEBAQMBAQEBJEcEBwULCwsGAwECAS4iBQ0BBQEUCAYTCYd+BgyfeJ12jXIBgSABDAQHEYNKA4kgjh+BKY4yFimEVRyBNQ X-IronPort-AV: E=Sophos;i="4.87,802,1363158000"; d="scan'208";a="21026851" Received: from mail-pd0-f177.google.com ([209.85.192.177]) by fe2.lbl.gov with ESMTP; 04 Jun 2013 13:34:01 -0700 Received: by mail-pd0-f177.google.com with SMTP id u10so753836pdi.22 for ; Tue, 04 Jun 2013 13:34:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=oOJ3+7yqRYNXBvIa48tHrxWyJCa/NG3CcJn5sR6aKrA=; b=PTlYeClZBimrkZui/UhW/hKzZZxHHoHCVr/CVwNQNcL/OUeWPKeL/EaoyQzVccWGhG G+wKsGYvgigh1Q3R/BRXItib27uJsakl6C+7SMyi62DtmSEi0wfAV18iVricEN3+bMzy HkhcmXcJKsJO0oFRoHz4fQGE6UixT9QDgbg+shLtzpvvqOlswz5L0OwZ8uX2LwzR7L9i WN5pCAU0QGhL67EkvkLnnJzTxxjPFwAq/K+SlQ+FAD1TF2+frTLbFfr2OHKP353oqZnB Uc238z6JqHy5wdHUh24q4YozRLnSgOjkv+6qRtvjKLqplDgxrWD65R1YqsGi1X6x4TQj m9lw== X-Received: by 10.68.132.101 with SMTP id ot5mr30017295pbb.11.1370378041795; Tue, 04 Jun 2013 13:34:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.132.101 with SMTP id ot5mr30017286pbb.11.1370378041667; Tue, 04 Jun 2013 13:34:01 -0700 (PDT) Received: by 10.68.182.194 with HTTP; Tue, 4 Jun 2013 13:34:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 13:34:01 -0700 Message-ID: From: Bruce Nordman To: Brad Schoening Content-Type: multipart/alternative; boundary=047d7b15a67761c46d04de5a001f X-Gm-Message-State: ALoCoQmfbn1GXmA1kYebknYP2M96jBD66ysqoXnU2kgQRAAyBA66fYboaFjskjzzEyGn189mKgx/fbO/5TfB1puMVkHAW6rmNDaPShf5bGCzgRJD3VBCsVHGAKEYbewx6HrRPhPKjJ8i Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:38:09 -0000 --047d7b15a67761c46d04de5a001f Content-Type: text/plain; charset=ISO-8859-1 *< A few minutes ago I sent a blank reply by accident; apologies >* For referencing the utility meter, we have the Domain part of the EMAN Framework, which notes that it is "... recommended to map 1:1 with a metered or sub-metered portion of the site." Problem solved. My comment did not question the inclusion of Domain. #1. For the Building-meter -> PDU -> Switch case, the Switch is Powered-by the PDU and the PDU is Powered-by the Building-meter. Plus, both specify that they are in the Domain of the Building-meter, so we have double referencing to the utility meter even without the Metered-by concept. #2. I agree with you that for EMAN there is no functional difference between a utility meter and a sub-meter. Furthermore, any meter is just a device in the EMAN context. It is a device with metering as its primary function but not different for EMAN purposes. Thanks, --Bruce On Mon, Jun 3, 2013 at 12:29 PM, Brad Schoening wrote: > BN: Would you say that a device should be able to reference the > utility meter that > is ultimately upstream from it? > > > Yes, absolutely. We did exactly that at Noveda. > > Consider the following: > > Building Smart Meter ----> Raritan Smart PDU (but no metering) ---> > Cisco Switch > > #1) How would you use MeteredBy for the PDU which doesn't have a meter? > CiscoSwitch Powered-by RaritanPDU seems necessary. > #2) Do you believe "utility meters" are functionally different from "smart > sub-meters"? I'm not sure I see any distinction. > > From: Bruce Nordman > Date: Mon, 3 Jun 2013 11:43:41 -0700 > > To: "John Parello (jparello)" > Cc: eman mailing list , eman issue tracker < > trac+eman@trac.tools.ietf.org> > Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed > > > > > On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) < > jparello@cisco.com> wrote: > >> Hi Bruce, >> >> Ah ok, so The core of your premise it that you think powered by and >> metered by are redundant. >> > Metered by is redundant to powered by, but I would not say the reverse is > true, so > step to solve this issue is to drop powered by. > >> >> Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 >> that I described 2) working systems that have this separated out and 3) >> the alignment with standard that recognize this that brad cited - I can't >> conclude that they are redundant. >> > > We are definitely going in circles here. > I addressed 1) in: > http://www.ietf.org/mail-archive/web/eman/current/msg01871.html > and have reproduced the text from that below. > I don't doubt 2), but that doesn't mean that doing so is something that > EMAN > needs to do or should do. > For 3), per my response a few minutes ago at: > http://www.ietf.org/mail-archive/web/eman/current/msg01882.html > my comment has nothing to do with the NIST definitions or to the utility > grid. > > Would you say that a device should be able to reference the utility > meter that > is ultimately upstream from it? > > Thanks, > > --Bruce > ------------------------------------- > My text from: > http://www.ietf.org/mail-archive/web/eman/current/msg01871.html > > Specifying that the the dedicated meter functionality you describe > is at a layer above the basic EMAN one of devices reporting about > themselves or devices they are connected to is intriguing, and one > I am quite sympathetic to, as a lot of system architectures these days > lack a good sense of layering and so become overly complex. > > This approach to a meter seems to then be properly part of an Energy > Management System that used EMAN and not part of the EMAN > protocol itself. > > In re-reviewing the Requirements document, I can't find reference to > dedicated meters as are being described here in a way that would > suggest that any special EMAN content is needed. I do think it would be > helpful to have a document describing EMS functions and how they > use EMAN and what else they do. That seems like the right place > for this dedicated meter proposal. > > It does seem clear that at the EMAN layer, the variety of energy > objects that we have - devices, components, and power interfaces - > are sufficient to fully implement it. > > Thanks, > > --Bruce > >> >> You posited that they are redundant so the burden is yours to show that >> and so far I don't see it. >> >> Jp >> >> >> Sent from my iPad >> (expect ridiculous spelling mistakes) >> > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov* > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > _______________________________________________ eman mailing list > eman@ietf.org https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b15a67761c46d04de5a001f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
< A few minutes ago I sent = a blank reply by accident; apologies >


For referencing th= e utility meter, we have the Domain part of the EMAN Framework,
which notes that it is "... recommended to map 1:1 with a metered or s= ub-metered portion of the site."
Problem solved.=A0 My commen= t did not question the inclusion of Domain.

#1. For the Buildi= ng-meter -> PDU -> Switch case, the Switch is Powered-by the PDU and = the PDU
is Powered-by the Building-meter.=A0 Plus, both specify that they are in th= e Domain of the
Building-meter, so we have double referencing to the uti= lity meter even without the Metered-by
concept.

#2. I= agree with you that for EMAN there is no functional difference between a u= tility
meter and a sub-meter.=A0 Furthermore, any meter is just a device in the EM= AN context.
It is a device with metering as its primary function b= ut not different for EMAN purposes.

Thanks,

--Bruce


On Mon, Jun 3, 2013 at 12:29 PM, Brad Schoening <brads@coraid.c= om> wrote:
is ultimately upstream from it?
Building Smart Meter =A0--= --> =A0Raritan Smart PDU (but no metering) =A0---> =A0Cisco Switch

#1) How would you use MeteredBy for the PDU which doesn't have a m= eter? =A0CiscoSwitch Powered-by RaritanPDU seems necessary.
#2) Do you believe "utility meters" are functionally differe= nt from "smart sub-meters"? =A0I'm not sure I see any distinc= tion.

From: Bruce Nordman <bnordman@lbl.gov>
Date: Mon, 3 Jun 2013 11:43:41 -070= 0

To: "John Parello (jparello)&q= uot; <jparello@c= isco.com>
Cc: eman mailing list <eman@ietf.org>, eman iss= ue tracker <trac+eman@trac.tools.ietf.org>
Subject: Re: [eman] #36: Cons= ider whether MeteredBy relationship is needed




On Mon, Jun 3, 2013 at 10:57 AM, John Parello (j= parello) <jparello@cisco.com> wrote:
Hi Bruce,

Ah ok, so The core of your premise it that you think powered by and me= tered by are redundant.
Metered by is redundant to powered by, but I would not say the reverse= is true, so
step to solve this issue is to drop powered by.

Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 t= hat I described =A02) working systems that have this separated out and 3) t= he alignment with standard that recognize this that brad cited - I can'= t conclude that they are redundant.=A0

We are definitely going in circles here.
and have reproduced the text from that below.
I don't doubt 2), but that doesn't mean that doing so is somet= hing that EMAN
needs to do or should do.
For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html
my comment has nothing to do with the NIST definitions or to the utili= ty grid.

Would you say that a device should be able to reference the utility me= ter that
is ultimately upstream from it?

Thanks,

--Bruce
-------------------------------------
My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html
=A0
Specifying that the the dedicated meter functionality you describe
is at a layer above the basic EMAN one of devices reporting about
themselves or devices they are connected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
lack a good sense of layering and so become overly complex.=A0

This approach to a meter seems to then be properly part of an Energy
Management System that used EMAN and not part of the EMAN
protocol itself.

In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would
suggest that any special EMAN content is needed.=A0 I do think it would be<= br> helpful to have a document describing EMS functions and how they
use EMAN and what else they do.=A0 That seems like the right place
for this dedicated meter proposal.

It does seem clear that at the EMAN layer, the variety of energy
objects that we have - devices, components, and power interfaces -
are sufficient to fully implement it.=A0

Thanks,

--Bruce

You posited that they are redundant so the burden is yours to sh= ow that and so far I don't see it.

Jp


Sent from my iPad=A0
(expect ridiculous spelling mistakes)=A0


--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 510-4= 86-7089
m: 51= 0-501-7943
_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman



--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
nordman.lbl.gov=
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b15a67761c46d04de5a001f-- From bnordman@lbl.gov Tue Jun 4 14:41:03 2013 Return-Path: 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 5052621F9A15 for ; Tue, 4 Jun 2013 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 ECBz7c9s39Oq for ; Tue, 4 Jun 2013 14:40:59 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id A7E7021F9A6D for ; Tue, 4 Jun 2013 13:24:38 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAEhMrlHRVaA2k2dsb2JhbABXA4JFdLZkiEVzCBYOAQEBAQcLCwkUBCSCIwEBAQMBAQEBJEcEBwULCwsGAwECAS4iBQ0BBQEUCAYTCYd+Bgyfd512jXIBgSABDAQHEYNKA4kgjh+BKY4yFimEVRyBNQ X-IronPort-AV: E=Sophos;i="4.87,802,1363158000"; d="scan'208";a="19358119" Received: from mail-pb0-f54.google.com ([209.85.160.54]) by fe1.lbl.gov with ESMTP; 04 Jun 2013 13:24:37 -0700 Received: by mail-pb0-f54.google.com with SMTP id ro2so741180pbb.13 for ; Tue, 04 Jun 2013 13:24:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=avC/4ZPIvWrRUBlQ+6zJ921W20oehB9lE5et49Ii1u4=; b=XIYM0F/sHI5MWkp3AN/ZoqFQK6DGWbit0F1YPlNjWZVNvettfYQbvLHkBrzACYHxGl Fi652YF5eNW7Ce6GZ0thkb+gzD8QiVf50k1dCfHq7CpUA+z8Y6PrP0VKiWEKqxJgft/C Z95m7UItkfbsF3iS/sr5MTRwnJ416To8CKie+6p490k7VKpSO9PSM6yfloAWU+IdSrfq fBRo1T7kgifocKWf/EXzQuAI6ne17WtvP7qZwtR/ZaRMLosZrakRcuUFTVAzy/WiQ8HJ 3y9opP1pV/yM5OAUr8L7l2bKPEzNKXBJzs+O0X6VI2W5soHAe8wZtb4UldHrnDXoxzJz Silw== X-Received: by 10.68.222.74 with SMTP id qk10mr29964081pbc.58.1370377477587; Tue, 04 Jun 2013 13:24:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.222.74 with SMTP id qk10mr29964075pbc.58.1370377477495; Tue, 04 Jun 2013 13:24:37 -0700 (PDT) Received: by 10.68.182.194 with HTTP; Tue, 4 Jun 2013 13:24:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 13:24:37 -0700 Message-ID: From: Bruce Nordman To: Brad Schoening Content-Type: multipart/alternative; boundary=047d7b2edf07c12ab504de59de3c X-Gm-Message-State: ALoCoQn8WHPRTZTKB8bYw5ADli/0jGTgj0vBnA6eTjmLzHUpCorjdgQ9cP0svvOrb1YmqqRc0NrxJpjQdmirrkTDURFSq+MkyW29I+dGgvbQXJa+FoWXsG2BBiUNmRgjXJ92zqz8U1Ma Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:41:03 -0000 --047d7b2edf07c12ab504de59de3c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 12:29 PM, Brad Schoening wrote: > BN: Would you say that a device should be able to reference the > utility meter that > is ultimately upstream from it? > > > Yes, absolutely. We did exactly that at Noveda. > > Consider the following: > > Building Smart Meter ----> Raritan Smart PDU (but no metering) ---> > Cisco Switch > > #1) How would you use MeteredBy for the PDU which doesn't have a meter? > CiscoSwitch Powered-by RaritanPDU seems necessary. > #2) Do you believe "utility meters" are functionally different from "smart > sub-meters"? I'm not sure I see any distinction. > > From: Bruce Nordman > Date: Mon, 3 Jun 2013 11:43:41 -0700 > > To: "John Parello (jparello)" > Cc: eman mailing list , eman issue tracker < > trac+eman@trac.tools.ietf.org> > Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed > > > > > On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) < > jparello@cisco.com> wrote: > >> Hi Bruce, >> >> Ah ok, so The core of your premise it that you think powered by and >> metered by are redundant. >> > Metered by is redundant to powered by, but I would not say the reverse is > true, so > step to solve this issue is to drop powered by. > >> >> Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 >> that I described 2) working systems that have this separated out and 3) >> the alignment with standard that recognize this that brad cited - I can't >> conclude that they are redundant. >> > > We are definitely going in circles here. > I addressed 1) in: > http://www.ietf.org/mail-archive/web/eman/current/msg01871.html > and have reproduced the text from that below. > I don't doubt 2), but that doesn't mean that doing so is something that > EMAN > needs to do or should do. > For 3), per my response a few minutes ago at: > http://www.ietf.org/mail-archive/web/eman/current/msg01882.html > my comment has nothing to do with the NIST definitions or to the utility > grid. > > Would you say that a device should be able to reference the utility > meter that > is ultimately upstream from it? > > Thanks, > > --Bruce > ------------------------------------- > My text from: > http://www.ietf.org/mail-archive/web/eman/current/msg01871.html > > Specifying that the the dedicated meter functionality you describe > is at a layer above the basic EMAN one of devices reporting about > themselves or devices they are connected to is intriguing, and one > I am quite sympathetic to, as a lot of system architectures these days > lack a good sense of layering and so become overly complex. > > This approach to a meter seems to then be properly part of an Energy > Management System that used EMAN and not part of the EMAN > protocol itself. > > In re-reviewing the Requirements document, I can't find reference to > dedicated meters as are being described here in a way that would > suggest that any special EMAN content is needed. I do think it would be > helpful to have a document describing EMS functions and how they > use EMAN and what else they do. That seems like the right place > for this dedicated meter proposal. > > It does seem clear that at the EMAN layer, the variety of energy > objects that we have - devices, components, and power interfaces - > are sufficient to fully implement it. > > Thanks, > > --Bruce > >> >> You posited that they are redundant so the burden is yours to show that >> and so far I don't see it. >> >> Jp >> >> >> Sent from my iPad >> (expect ridiculous spelling mistakes) >> > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov* > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > _______________________________________________ eman mailing list > eman@ietf.org https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b2edf07c12ab504de59de3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 3, 2013 at 12:29 PM, Brad Schoening <brads@coraid= .com> wrote:
BN: Would you say that a device should be able to reference the utilit= y meter that
is ultimately upstream from it?

Yes, absolutely. =A0We did exactly that at Noveda.

Consider the following:

Building Smart Meter =A0--= --> =A0Raritan Smart PDU (but no metering) =A0---> =A0Cisco Switch

#1) How would you use MeteredBy for the PDU which doesn't have a m= eter? =A0CiscoSwitch Powered-by RaritanPDU seems necessary.
#2) Do you believe "utility meters" are functionally differe= nt from "smart sub-meters"? =A0I'm not sure I see any distinc= tion.

From: Bruce Nordman <bnordman@lbl.gov>
Date: Mon, 3 Jun 2013 11:43:41 -070= 0

To: "John Parello (jparello)&q= uot; <jparello@c= isco.com>
Cc: eman mailing list <eman@ietf.org>, eman iss= ue tracker <trac+eman@trac.tools.ietf.org>
Subject: Re: [eman] #36: Cons= ider whether MeteredBy relationship is needed




On Mon, Jun 3, 2013 at 10:57 AM, John Parello (j= parello) <jparello@cisco.com> wrote:
Hi Bruce,

Ah ok, so The core of your premise it that you think powered by and me= tered by are redundant.
Metered by is redundant to powered by, but I would not say the reverse= is true, so
step to solve this issue is to drop powered by.

Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 t= hat I described =A02) working systems that have this separated out and 3) t= he alignment with standard that recognize this that brad cited - I can'= t conclude that they are redundant.=A0

We are definitely going in circles here.
and have reproduced the text from that below.
I don't doubt 2), but that doesn't mean that doing so is somet= hing that EMAN
needs to do or should do.
For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html
my comment has nothing to do with the NIST definitions or to the utili= ty grid.

Would you say that a device should be able to reference the utility me= ter that
is ultimately upstream from it?

Thanks,

--Bruce
-------------------------------------
My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html
=A0
Specifying that the the dedicated meter functionality you describe
is at a layer above the basic EMAN one of devices reporting about
themselves or devices they are connected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
lack a good sense of layering and so become overly complex.=A0

This approach to a meter seems to then be properly part of an Energy
Management System that used EMAN and not part of the EMAN
protocol itself.

In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would
suggest that any special EMAN content is needed.=A0 I do think it would be<= br> helpful to have a document describing EMS functions and how they
use EMAN and what else they do.=A0 That seems like the right place
for this dedicated meter proposal.

It does seem clear that at the EMAN layer, the variety of energy
objects that we have - devices, components, and power interfaces -
are sufficient to fully implement it.=A0

Thanks,

--Bruce

You posited that they are redundant so the burden is yours to sh= ow that and so far I don't see it.

Jp


Sent from my iPad=A0
(expect ridiculous spelling mistakes)=A0


--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 510-4= 86-7089
m: 51= 0-501-7943
_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman



--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
nordman.lbl.gov=
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b2edf07c12ab504de59de3c-- From bnordman@lbl.gov Tue Jun 4 14:41:37 2013 Return-Path: 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 23BDC21F92C5 for ; Tue, 4 Jun 2013 14:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 oDIRoj-o0mK4 for ; Tue, 4 Jun 2013 14:41:32 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 474EF21F944C for ; Tue, 4 Jun 2013 13:37:25 -0700 (PDT) X-Ironport-SBRS: 4.1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAJNOrlHRVaA0jWdsb2JhbABXA4JFdLZkiEVzCBYOAQEBAQcLCwkSBiSCGwgBAQQBbgQHBQsLCwMDBAEBKAciEgEFAQsJCAYTCYVtghEGDJ94nXaNcgGBIRAGARGCRIEGA4kgik2DUoEpjjIWKYRVHIE1 X-IronPort-AV: E=Sophos;i="4.87,802,1363158000"; d="scan'208";a="19359698" Received: from mail-pb0-f52.google.com ([209.85.160.52]) by fe1.lbl.gov with ESMTP; 04 Jun 2013 13:37:24 -0700 Received: by mail-pb0-f52.google.com with SMTP id xa12so749831pbc.39 for ; Tue, 04 Jun 2013 13:37:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/KVbkRtF7AGEPTD+rdKH5eYI/Dn3xSd+QX/PIOi67lc=; b=b7pJL3zhxoFRGEYSfdeKR0uEL08Rm+dAUbzBBylbuJfVlqElm8wov2reOoERxVfvGn bjAEGCUf31U9NIbxV7osz0okYpf2G/OPjGWqhl10/5yFljQwIhnq89pjwsGrPLgzCJGh 2YzFyh6+UpyAEZR2x5sotVx6MrKgL57XPwZ/QFhtURwWtpnn9s63NnxZx2XYL/LziP/y HsCz/EDWu+vwSLCK5RkiiSUfwoOTAFTpBgdlCvAgE9ddln2UyhdoOPmmt0e5G3LWshlM FUZJgnuMk0JWj1Cx1oYtAQtoTvmyCCoCdr5zhSlCAZq010NiSZSkhj7rTs8OQHOmTg6s 88OQ== X-Received: by 10.66.189.130 with SMTP id gi2mr30816350pac.89.1370378244474; Tue, 04 Jun 2013 13:37:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.189.130 with SMTP id gi2mr30816344pac.89.1370378244387; Tue, 04 Jun 2013 13:37:24 -0700 (PDT) Received: by 10.68.182.194 with HTTP; Tue, 4 Jun 2013 13:37:24 -0700 (PDT) In-Reply-To: References: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> <070.6088bf1f90de3048ca60ae728c334000@trac.tools.ietf.org> <06C7C921-686A-466D-9ADE-6E0E1B4ED76D@cisco.com> <32ADE20B-7387-4A80-927A-C6F2B1DBA904@cisco.com> <75701DE1-E567-4121-9A19-CEE81FF6C603@cisco.com> Date: Tue, 4 Jun 2013 13:37:24 -0700 Message-ID: From: Bruce Nordman To: Georgios Karagiannis Content-Type: multipart/alternative; boundary=047d7bf0d4127707ce04de5a0c7a X-Gm-Message-State: ALoCoQnl0BglQBympp6soJsZLpvACtsSpfgS2tVbPEYiTqeOOJlvfv0wZq/YwYb5EnGgS6jTKlOXAoHMdIi55x5LrxOGqicIayBT60lnwgBH2ZEW9wpK54GBXXd6lcLcoAdvsbJeMCah Cc: eman mailing list , trac+eman@grenache.tools.ietf.org Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:41:37 -0000 --047d7bf0d4127707ce04de5a0c7a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Georgios-- In re-reading that section of the Applicability Statement, I don't see what is not covered by using Powered-by (possibly supplemented by Domain). A specific example would be helpful, as would some pointers to content in the Requirements draft. Thanks, --Bruce On Tue, Jun 4, 2013 at 2:57 AM, wrote: > Hi all,**** > > ** ** > > I agree with John, the MeteredBy relationship is needed for the support o= f > several scenarios, see e.g., =93Home energy gateways=94 scenario in sec= tion > 2.7 of:**** > > http://www.ietf.org/id/draft-ietf-eman-applicability-statement-03.txt**** > > ** ** > > Best regards,**** > > Georgios**** > > ** ** > > ** ** > > ** ** > > *From:* eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf > Of *John Parello (jparello) > *Sent:* dinsdag 4 juni 2013 0:36 > *To:* Bruce Nordman > *Cc:* eman mailing list; eman issue tracker > *Subject:* Re: [eman] #36: Consider whether MeteredBy relationship is > needed**** > > ** ** > > Hi Bruce,**** > > ** ** > > Definitely not going in circles. I considered it and I don't agree the > relationships are redundant in any order for the reasons I outlined. **** > > ** ** > > Jp**** > > ** ** > > ** ** > > Sent from my iPad **** > > (expect ridiculous spelling mistakes) **** > > > On Jun 3, 2013, at 11:43 AM, "Bruce Nordman" wrote:***= * > > ** ** > > ** ** > > On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jparello) < > jparello@cisco.com> wrote:**** > > Hi Bruce,**** > > ** ** > > Ah ok, so The core of your premise it that you think powered by and > metered by are redundant.**** > > Metered by is redundant to powered by, but I would not say the reverse is > true, so**** > > step to solve this issue is to drop powered by.**** > > ** ** > > Given 1) the analogyy in modeling indescribes to layer-2 and layer-3 that > I described 2) working systems that have this separated out and 3) the > alignment with standard that recognize this that brad cited - I can't > conclude that they are redundant. **** > > ** ** > > We are definitely going in circles here.**** > > I addressed 1) in: > http://www.ietf.org/mail-archive/web/eman/current/msg01871.html**** > > and have reproduced the text from that below.**** > > I don't doubt 2), but that doesn't mean that doing so is something that > EMAN > needs to do or should do.**** > > For 3), per my response a few minutes ago at: > http://www.ietf.org/mail-archive/web/eman/current/msg01882.html**** > > my comment has nothing to do with the NIST definitions or to the utility > grid.**** > > Would you say that a device should be able to reference the utility meter > that**** > > is ultimately upstream from it?**** > > ** ** > > Thanks,**** > > --Bruce > -------------------------------------**** > > My text from: > http://www.ietf.org/mail-archive/web/eman/current/msg01871.html > **** > > Specifying that the the dedicated meter functionality you describe > is at a layer above the basic EMAN one of devices reporting about > themselves or devices they are connected to is intriguing, and one > I am quite sympathetic to, as a lot of system architectures these days > lack a good sense of layering and so become overly complex. **** > > This approach to a meter seems to then be properly part of an Energy > Management System that used EMAN and not part of the EMAN > protocol itself.**** > > > In re-reviewing the Requirements document, I can't find reference to > dedicated meters as are being described here in a way that would > suggest that any special EMAN content is needed. I do think it would be > helpful to have a document describing EMS functions and how they > use EMAN and what else they do. That seems like the right place > for this dedicated meter proposal.**** > > It does seem clear that at the EMAN layer, the variety of energy > objects that we have - devices, components, and power interfaces - > are sufficient to fully implement it. **** > > Thanks,**** > > ** ** > > --Bruce**** > > ** ** > > You posited that they are redundant so the burden is yours to show that > and so far I don't see it.**** > > ** ** > > Jp**** > > ** ** > > > Sent from my iPad **** > > (expect ridiculous spelling mistakes) **** > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov* > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943**** > > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7bf0d4127707ce04de5a0c7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Georgios--
=A0 In re-reading that section of = the Applicability Statement, I don't see
what is not covered by usin= g Powered-by (possibly supplemented
by Domain).=A0 A specific example wo= uld be helpful, as would some
pointers to content in the Requirements draft.
Thanks,<= br>
--Bruce


On Tue, Jun 4, 2013 at 2:57 AM, <karagian@cs.utwente.nl= > wrote:

Hi all,

=A0<= /p>

I agree wi= th John, the MeteredBy relationship is needed for the support of several sc= enarios, see e.g., =A0=A0=93Home energy gateways=94 scenario in section 2.7 of:

http://www.ietf.org/id/draft-ietf-eman-applicability-stateme= nt-03.txt

=A0=

Best regar= ds,

Georgios

=A0=

=A0=

=A0=

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello)
Sent: dinsdag 4 juni 2013 0:36
To: Bruce Nordman
Cc: eman mailing list; eman issue tracker
Subject: Re: [eman] #36: Consider whether MeteredBy relationship is = needed

=A0

Hi Bruce,

=A0

Definitely not going in circles. I considered it and= I don't agree the relationships are redundant in any order for the rea= sons I outlined.=A0

=A0

Jp

=A0

=A0

Sent from my iPad=A0

(expect ridiculous spelling mistakes)=A0


On Jun 3, 2013, at 11:43 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

=A0

=A0

On Mon, Jun 3, 2013 at 10:57 AM, John Parello (jpare= llo) <jparello@c= isco.com> wrote:

Hi Bruce,

=A0

Ah ok, so The core of your premise it that you think= powered by and metered by are redundant.

Metered by is redundant to powered by, but I would n= ot say the reverse is true, so

step to solve this issue is to drop powered by.

=A0

Given 1) the analogyy in modeling indescribes to lay= er-2 and layer-3 that I described =A02) working systems that have this sepa= rated out and 3) the alignment with standard that recognize this that brad = cited - I can't conclude that they are redundant.=A0

=A0

We are definitely going in circles here.

and have reproduced the text from that below.=

I don't doubt 2), but that doesn't mean that= doing so is something that EMAN
needs to do or should do.

For 3), per my response a few minutes ago at: http://www.ietf.org/mail-archive/web/eman/current/msg01882.html<= u>

my comment has nothin= g to do with the NIST definitions or to the utility grid.

Would you say that a device should be able to refere= nce the utility meter that

is ultimately upstream from it?

=A0

Thanks,=

--Bruce
-------------------------------------

My text from: http://www.ietf.org/mail-archive/web/eman/current/msg01871.html
=A0

Specifying that the t= he dedicated meter functionality you describe
is at a layer above the basic EMAN one of devices reporting about
themselves or devices they are connected to is intriguing, and one
I am quite sympathetic to, as a lot of system architectures these days
lack a good sense of layering and so become overly complex.=A0

This approach to a meter seems to then be properly p= art of an Energy
Management System that used EMAN and not part of the EMAN
protocol itself.


In re-reviewing the Requirements document, I can't find reference to dedicated meters as are being described here in a way that would
suggest that any special EMAN content is needed.=A0 I do think it would be<= br> helpful to have a document describing EMS functions and how they
use EMAN and what else they do.=A0 That seems like the right place
for this dedicated meter proposal.

It does seem clear th= at at the EMAN layer, the variety of energy
objects that we have - devices, components, and power interfaces -
are sufficient to fully implement it.=A0

Thanks,

=A0

--Bruce

=A0

You posited that they are redundant so the burden is= yours to show that and so far I don't see it.

=A0

Jp

=A0


Sent from my iPad=A0

(expect ridiculous spelling mistakes)=A0



--
Bruce Nordman
Lawrence Berkeley National Laboratory<= br> nordman.lbl.gov
BNordman@LBL.gov<= br> 510-4= 86-7089
m: 51= 0-501-7943




--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
nordman.lbl.gov=
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7bf0d4127707ce04de5a0c7a-- From bnordman@lbl.gov Tue Jun 4 14:42:59 2013 Return-Path: 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 F385D21F9A63 for ; Tue, 4 Jun 2013 14:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 vLK6Q2rbluLA for ; Tue, 4 Jun 2013 14:42:54 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id BD0A321F9C3B for ; Tue, 4 Jun 2013 14:15:21 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAMRXrlHRVaAxk2dsb2JhbABXA4JFdLZkiEV1CBYOAQEBAQcLCwkUBCSCIwEBBAFyBwULCwQHOyISAQUBHAYTiAcGn3qddo1iGoEYEAcRg0oDiSCOH4EpjjIWKYRVHIE1 X-IronPort-AV: E=Sophos;i="4.87,802,1363158000"; d="scan'208";a="19365063" Received: from mail-pb0-f49.google.com ([209.85.160.49]) by fe1.lbl.gov with ESMTP; 04 Jun 2013 14:15:21 -0700 Received: by mail-pb0-f49.google.com with SMTP id jt11so796492pbb.36 for ; Tue, 04 Jun 2013 14:15:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZD+6nov/bCFYWPf7wpe5a0JevqMz3knOH6cZZ+JkGDg=; b=h3Q57zJZ4QF9FuJPIEMRpVVUCvGOi/MAWvHUKtWFqk2uzBPZ3nFNuVvSfA/tI28rCc MMIpTPeD4VbfB3vQsZpZ7GobeKVIxQGztvqKjvtJzNPwcNYMNc+jyNYEs82AkXS+Lmjt I9g6lmbGIFzvaiQzXBW3yBzxCVjNpw8kXRxoy71wUa2H+KziTjZwHY6IhjEtV7RwRfR2 YJjKdCe4bPuL8THBvRQl5DQiW/xQPQJ260rLvW45hCEAkNTRkLDKgNkcR4TweQjjrEPI FxuTb43nc/ysYNwf8goixCTOPnunigzT9xzVZ7j1t3kfIKfXbPjx0I6Lhhs7wj2goZGo Huqw== X-Received: by 10.66.149.170 with SMTP id ub10mr30690072pab.58.1370380521073; Tue, 04 Jun 2013 14:15:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.149.170 with SMTP id ub10mr30690069pab.58.1370380521014; Tue, 04 Jun 2013 14:15:21 -0700 (PDT) Received: by 10.68.182.194 with HTTP; Tue, 4 Jun 2013 14:15:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 14:15:20 -0700 Message-ID: From: Bruce Nordman To: Brad Schoening Content-Type: multipart/alternative; boundary=047d7b6dc2f2298d0704de5a949b X-Gm-Message-State: ALoCoQlPDN2cg6oM0F9kHNXjUzeN9yO3n02Rg7DpiHE0vUIJIv1tOGpc9ry9UadVCbU462uuicrW/c1BD7y8t8Z+DpxrrBNsTq6NdZlcBLqT+AOpuQ08/bAmNJJAmB2HPY4HggdbW+XR Cc: eman mailing list , eman issue tracker Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:42:59 -0000 --047d7b6dc2f2298d0704de5a949b Content-Type: text/plain; charset=ISO-8859-1 That would be a typo in my Monday email - should have been "metered by". Ticket is: "Consider whether MeteredBy relationship is needed" and the full sentence from my Monday email is: Metered by is redundant to powered by, but I would not say the reverse is true, so step to solve this issue is to drop powered by. (and last two words should of course be "metered by"). I hope that makes it clear what I am identifying is redundant. Thanks, --Bruce On Tue, Jun 4, 2013 at 2:08 PM, Brad Schoening wrote: > Bruce, > > I'm not sure I understand which relationship you are suggesting is > redundant. Below you use the PowerBy relationship, while on Monday, you > stated "so step to solve this issue is to drop powered by." > > Regards, > > Brad > .. > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b6dc2f2298d0704de5a949b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That would be a typo in my Monday email - should= have been "metered by".

Ticket is:=A0 "Conside= r whether MeteredBy relationship is needed" and
the full sent= ence from my Monday email is:=A0
=A0=A0=A0 Metered by is redundant to powered by, but I would not say the re= verse is true,
=A0=A0=A0 so step to solve this issue is to drop powered by.
(and last two words sho= uld of course be "metered by").

I hope that mak= es it clear what I am identifying is redundant.

Thanks,

--Bruce

<= br>
On Tue, Jun 4, 2013 at 2:08 PM, Brad Schoenin= g <brads@coraid.com> wrote:
Bruce,

I'm not sure I understand which relationship you are suggesting is= redundant. =A0Below you use the PowerBy relationship, while on Monday, you= stated "so=A0step to solve this issue is to drop powered by." = =A0

Regards,

Brad
..
--
Bruce Nordman
La= wrence Berkeley National Laboratory
nordman.lbl.g= ov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b6dc2f2298d0704de5a949b-- From trac+eman@trac.tools.ietf.org Tue Jun 11 11:45:16 2013 Return-Path: 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 2561121F9943 for ; Tue, 11 Jun 2013 11:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 K9OAJkVZudyo for ; Tue, 11 Jun 2013 11:45:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77A21F9997 for ; Tue, 11 Jun 2013 11:45:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:42419 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmTYy-0007f3-42; Tue, 11 Jun 2013 20:45:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com X-Trac-Project: eman Date: Tue, 11 Jun 2013 18:45:00 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/31#comment:2 Message-ID: <072.ade4c0df5d0f4d353721b8fa93491658@trac.tools.ietf.org> References: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Resent-Message-Id: <20130611184508.3E77A21F9997@ietfa.amsl.com> Resent-Date: Tue, 11 Jun 2013 11:45:07 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #31: Clarify what is optional to implment in the UML X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:45:16 -0000 #31: Clarify what is optional to implment in the UML Comment (by jparello@cisco.com): Proposed UML to date EMAN INFORMATION MODEL class EnergyObject { // identification index : int identifier : uuid alternatekey : string eotype : enum { device, component, inlet, outlet } eocategory : enum { producer, consumer, meter } // NOTE: Distributor? // context domainName : string role : string keywords [0..n] : string importance : int // relationship relationships [0..n] : Relationship // measurements nameplate : Nameplate // power and energy power : PowerMeasurement energy : EnergyMeasurment demand : DemandMeasurement // power states powerControl [0..n] : PowerStateSet } class Relationship { relationshipType : enum { meters, meteredby, powers, poweredby, aggregates, aggregatedby } relationshipObject : uuid } // NOTE: No consensus on Proxy so I didn't put it in . Remove? Yes no consensus. // Should this be IANA. See Gellish. // Can drop discussion on generic Parent/Child // General: information model registry class Nameplate { nominalPower : PowerMeasurement details : URI } class Measurement { multiplier: enum { -24..24} caliber : enum { actual, estimated, trusted, assumed } // IANA?? accuracy : enum { 0..10000} // hundreds of percent } class PowerMeasurement extends Measurement { value : long units : "W" rate : enum { 0, milliseconds, seconds, minutes, hours} // Brad find out what the rate was not in mib delete this. powerAttribute : PowerAttribute } class EnergyMeasurement extends Measurement { startTime : time units : "Wh" provided : long used : long produced : long } class TimedMeasurement extends Measurement { startTime : timestamp value : Measurement maximum : Measurement } class TimeInterval { value : long units : enum { seconds, miliseconds,...} } class DemandMeasurement extends Measurement { intervalLength : TimeInterval interval : long intervalMode : enum { periodic, sliding, total } intervalWindow : TimeInterval sampleRate : TimeInterval status : enum { active, inactive } measurements[0..n] : TimedMeasurements } class PowerStateSet { powerSetIdentifier : int name : string powerStates [0..n] : PowerState operState : int adminState : int reason : string configuredTime : timestamp } class PowerState { powerStateIdentifier : int name : string cardinality : int maximumPower : PowerMeasurement totalTimeInState : time entryCount : long } // Power Attributes for next week should be identical as in doc now... jparello 6/9/2013 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-eman-applicability- jparello@cisco.com | statement@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: applicability- | Resolution: statement | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: eman From n.brownlee@auckland.ac.nz Tue Jun 11 15:12:02 2013 Return-Path: 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 CF92921F9A3E for ; Tue, 11 Jun 2013 15:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOW=2.3, USER_IN_WHITELIST=-100] 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 1jUeJvWb-o5b for ; Tue, 11 Jun 2013 15:11:58 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 36DCA21F997C for ; Tue, 11 Jun 2013 15:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1370988718; x=1402524718; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UGyOZQL48mU2mD+N+nTnHsaxBJGuzrZIYGgENtN+2fc=; b=PjOaoSQ/rb7qerTYyEg4sMjWRsvfW+8I13VLML2mt8nyoS2Uts4Qvslv te5IMlTWKNlpVusQYPnmYOe6W7inv+v3RxWpu643Tv6hrymTCy9QwRG7p BNMz5MbneCw6EGYOPDT7t1lFtHnv+nf2Z9slcfA5gEEdAxmLtTbUHQj2o E=; X-IronPort-AV: E=Sophos;i="4.87,847,1363086000"; d="scan'208";a="193873924" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 12 Jun 2013 10:11:55 +1200 Message-ID: <51B7A0AA.4080902@auckland.ac.nz> Date: Wed, 12 Jun 2013 10:11:54 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ira McDonald References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] Please add PWG power states to EMAN Framework X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:12:02 -0000 Hi Ira: Following up on your email dated 29 May, we've discussed the PWG power states, and are happy to add them into the EMAN Framework's Power State Sets. However, looking at the PWG states, we feel it's not a good idea to have little subsets for particular vendors as part of the PWG state set. That's mostly because it won't scale to a large number of vendors. From an IANA point of view, it would be better to have a separate IANA registry for Vendor-specific power states - that way, when a new vendor needs particular states they could simply ask IANA to add them to that registry. For now, we see three possible ways forward: 1. Add PWG's power states, leaving out its vendor-specific states. 2. Leave the PWG states out of the EMAN power states for now; they could be added later by asking IANA to register them (they'd probably be subject to Expert review at that point). 3. Discuss having a Vendor-specific Power States Registry with IANA. Would you please consider these possibilities, and let me know which you'd like us to proceed with. Speaking only for myself, I suggest that the question is "how important is it for PWG to have vendor-specific power states?" Cheers, Nevil (EMAN co-chair) On 29/05/13 10:31 AM, Ira McDonald wrote: > Hi, > > I understand that the EMAN Framework document > will request IANA to create some initial sets of power > states. We would like this to include the PWG's power > state set for imaging devices. That can be found at > the following link and the states (and numeric codes) > from that are listed below. > > The stable reference for IEEE-ISTO PWG power state > names and numeric values is the PWG Imaging System > Power MIB (PWG 5106.5-2011) archived at: > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib > > On line 50 is the PowPowerStateTC definition, which uses > the DMTF CIM power states multiplied by 10 w/ inserted > vendor sub-states for a few stable (non-transient) states, > as follows: > > PowPowerStateTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The power state of this component (System or Subunit). > > Usage: Vendor extensions allowed ONLY for primary power states > (on, standby, suspend, hibernate, and offSoft). Vendor > extensions are intentionally not defined for reset or > interrupts." > REFERENCE > "Table 3 in section 7.3 in DMTF CIM Power Profile (DSP 1027)." > SYNTAX INTEGER { > other(1), > -- DO NOT USE > unknown(2), -- initial default ONLY > on(20), -- On - fully operational > onVendor1(21), > onVendor2(22), > onVendor3(23), > onVendor4(24), > onVendor5(25), > standby(30), -- Standby - light sleep > standbyVendor1(31), > standbyVendor2(32), > standbyVendor3(33), > standbyVendor4(34), > standbyVendor5(35), > suspend(40), -- Suspend - deep sleep > suspendVendor1(41), > suspendVendor2(42), > suspendVendor3(43), > suspendVendor4(44), > suspendVendor5(45), > resetSoft(50), -- Reset - soft reset > offHard(60), -- Off Hard - no power consumed > hibernate(70), -- Hibernate - context save, off > hibernateVendor1(71), > hibernateVendor2(72), > hibernateVendor3(73), > hibernateVendor4(74), > hibernateVendor5(75), > offSoft(80), -- Off Soft - w/ auxiliary power > offSoftVendor1(81), > offSoftVendor2(82), > offSoftVendor3(83), > offSoftVendor4(84), > offSoftVendor5(85), > resetHard(90), -- hard off, power on > resetMBR(100), -- Master Bus Reset > resetNMI(110), -- Non-Maskable Interrupt > offSoftGraceful(120), -- orderley shutdown, soft off > offHardGraceful(130), -- orderly shutdown, hard off > resetMBRGraceful(140), -- orderly shutdown, MBR reset > resetSoftGraceful(150), -- orderly shutdown, soft reset > resetHardGraceful(160), -- orderly shutdown, hard reset > resetINIT(170), -- Diagnostic Interrupt (INIT) > notApplicable(180), > noChange(190) > } > > Thanks, > - Ira (editor of PWG Power MIB and PWG Secretary). > > > 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/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 > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trac+eman@trac.tools.ietf.org Tue Jun 11 15:16:56 2013 Return-Path: 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 1B33E21F8EFE for ; Tue, 11 Jun 2013 15:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 R09117PiIJCt for ; Tue, 11 Jun 2013 15:16:54 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9F67C21F8EF7 for ; Tue, 11 Jun 2013 15:16:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:56556 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmWrv-0001By-GX; Wed, 12 Jun 2013 00:16:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bclaise@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:16:47 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/37 Message-ID: <064.f30108e53f3866acdfaad56b48af86d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bclaise@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: [eman] #37: Determine how best to include PWG power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:16:56 -0000 #37: Determine how best to include PWG power states The PWG power states include vendor-specific states; how should we handle this? We discussed three possible ways forward: 1. Add PWG's power states, leaving out its vendor-specific states. 2. Leave the PWG states out of the EMAN power states for now; they could be added later by asking IANA to register them (they'd probably be subject to Expert review at that point). 3. Discuss having a Vendor-specific Power States Registry with IANA. Nevil has asked Ira McDonald (PWG) how we should proceed. Also, we note that - the PWG states include several 'operational' states - the PWG states will need to be reflected in the EMAN Monitoring MIB -- ---------------------------------------+------------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: bclaise@cisco.com Type: defect | Status: new Priority: major | Milestone: milestone1 Component: applicability-statement | Version: Severity: - | Keywords: ---------------------------------------+------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 15:18:27 2013 Return-Path: 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 61E9821F9A23 for ; Tue, 11 Jun 2013 15:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LC6BgLi6swwI for ; Tue, 11 Jun 2013 15:18:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C731721F99E3 for ; Tue, 11 Jun 2013 15:18:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:56576 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmWtN-0000Qi-KD; Wed, 12 Jun 2013 00:18:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-framework@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:18:17 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/30#comment:4 Message-ID: <079.dfd0fa179dab1589d98333a34d8e507f@trac.tools.ietf.org> References: <064.8f201006117e8f657bd861e1408c12db@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <064.8f201006117e8f657bd861e1408c12db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-framework@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bclaise@cisco.com, bnordman@lbl.gov, brad.schoening@verizon.net, jparello@cisco.com, quittek@netlab.nec.de Resent-Message-Id: <20130611221826.C731721F99E3@ietfa.amsl.com> Resent-Date: Tue, 11 Jun 2013 15:18:26 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #30: Power State and Power State Sets introduction X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:18:27 -0000 #30: Power State and Power State Sets introduction Comment (by n.brownlee@auckland.ac.nz): Everyone to review these changes so that we can close this ticket. - Benoit says "OK to close" -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-eman- n.brownlee@auckland.ac.nz | framework@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 15:22:15 2013 Return-Path: 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 4185921F9A64 for ; Tue, 11 Jun 2013 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vWkikKBHBulV for ; Tue, 11 Jun 2013 15:22:14 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 835DB21F9A4C for ; Tue, 11 Jun 2013 15:22:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:56750 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmWx6-00032n-VC; Wed, 12 Jun 2013 00:22:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:22:08 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/31#comment:3 Message-ID: <072.21626d8d55f4bcf135b3180223e3eb31@trac.tools.ietf.org> References: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Resent-Message-Id: <20130611222214.835DB21F9A4C@ietfa.amsl.com> Resent-Date: Tue, 11 Jun 2013 15:22:14 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #31: Clarify what is optional to implment in the UML X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:22:15 -0000 #31: Clarify what is optional to implment in the UML Comment (by n.brownlee@auckland.ac.nz): Benoit will check this further. We will need to register our Textual Convention and its types with IANA; the TC is IANAPowerStateSet, defined in the EMAN Monitoring MIB. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-eman-applicability- jparello@cisco.com | statement@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: applicability- | Resolution: statement | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 15:26:30 2013 Return-Path: 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 8C14221F9A4B for ; Tue, 11 Jun 2013 15:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 q-xnJAjKkQrq for ; Tue, 11 Jun 2013 15:26:29 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 83CDA21F9A13 for ; Tue, 11 Jun 2013 15:26:29 -0700 (PDT) Received: from localhost ([127.0.0.1]:57188 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmX1F-0000fh-1N; Wed, 12 Jun 2013 00:26:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:26:25 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/31#comment:4 Message-ID: <072.1cb0234d81c9c684f1f9ca1c794cd5be@trac.tools.ietf.org> References: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Resent-Message-Id: <20130611222629.83CDA21F9A13@ietfa.amsl.com> Resent-Date: Tue, 11 Jun 2013 15:26:29 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #31: Clarify what is optional to implment in the UML X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:26:30 -0000 #31: Clarify what is optional to implment in the UML Comment (by n.brownlee@auckland.ac.nz): Question: what's the 'rate' in the PowerMeasurement class? Brad to check this. Another thought: we agreed that the Information Model needs to be expressed in UML within the Framework document. Would it also be useful to include the above as an appendix? It's in Gellic English, which Wikipedia tells me is a formal language for defining Information Models; Wikipedia also gives a reference for it. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-eman-applicability- jparello@cisco.com | statement@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: applicability- | Resolution: statement | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 15:32:46 2013 Return-Path: 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 51FEC21F9A3A for ; Tue, 11 Jun 2013 15:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FJ7IMiQAW+7l for ; Tue, 11 Jun 2013 15:32:45 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3821F9A38 for ; Tue, 11 Jun 2013 15:32:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:57366 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmX7D-000481-6U; Wed, 12 Jun 2013 00:32:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:32:35 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/31#comment:5 Message-ID: <072.605a2dc3703369c7363329af17f79676@trac.tools.ietf.org> References: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <057.ccb90ad9c9aa4c2bd5890f771e3fe09a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Resent-Message-Id: <20130611223245.C0B3821F9A38@ietfa.amsl.com> Resent-Date: Tue, 11 Jun 2013 15:32:45 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #31: Clarify what is optional to implment in the UML X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:32:46 -0000 #31: Clarify what is optional to implment in the UML Comment (by n.brownlee@auckland.ac.nz): Ongoing activities: - discuss this on the EMAN list - check it with Brian Hedstrom (Cable Labs) - John will add ACQuality to the Gellish description -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-eman-applicability- jparello@cisco.com | statement@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: applicability- | Resolution: statement | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 15:33:23 2013 Return-Path: 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 8E90F21F99D9 for ; Tue, 11 Jun 2013 15:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 D5VeJHV5dcca for ; Tue, 11 Jun 2013 15:33:21 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFEC21F9A49 for ; Tue, 11 Jun 2013 15:33:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:57475 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmX7m-000617-JP; Wed, 12 Jun 2013 00:33:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:33:10 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/eman/trac/ticket/32#comment:1 Message-ID: <072.e23403c7e076119f5d00446229fc4b94@trac.tools.ietf.org> References: <057.15e05ea239a6d1bbd3e57c700b0325ba@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <057.15e05ea239a6d1bbd3e57c700b0325ba@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Resent-Message-Id: <20130611223319.1AFEC21F9A49@ietfa.amsl.com> Resent-Date: Tue, 11 Jun 2013 15:33:18 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #32: Add a nameplate class to the model X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:33:23 -0000 #32: Add a nameplate class to the model Changes (by n.brownlee@auckland.ac.nz): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-eman-applicability- jparello@cisco.com | statement@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: | Version: applicability- | Resolution: fixed statement | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 15:34:06 2013 Return-Path: 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 A4DBF21F90E4 for ; Tue, 11 Jun 2013 15:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 VHG5H23lUbTN for ; Tue, 11 Jun 2013 15:34:05 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B972821F919D for ; Tue, 11 Jun 2013 15:34:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:57612 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmX8c-0004xm-MN; Wed, 12 Jun 2013 00:34:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: brads@coraid.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:34:02 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/eman/trac/ticket/36#comment:3 Message-ID: <070.a2b54bc931b351a7446ad1b527e1b92d@trac.tools.ietf.org> References: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <055.964305967ace508a59178ce1e8196f7b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #36: Consider whether MeteredBy relationship is needed X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:34:06 -0000 #36: Consider whether MeteredBy relationship is needed Changes (by n.brownlee@auckland.ac.nz): * status: new => closed * resolution: => fixed -- ------------------------------+--------------------- Reporter: bnordman@lbl.gov | Owner: Bruce Type: defect | Status: closed Priority: major | Milestone: Component: framework | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 15:35:19 2013 Return-Path: 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 855BB21F9A4C for ; Tue, 11 Jun 2013 15:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9VF0-5Sqlpa5 for ; Tue, 11 Jun 2013 15:35:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F131C21F9A49 for ; Tue, 11 Jun 2013 15:35:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:57790 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmX9j-0007z6-IW; Wed, 12 Jun 2013 00:35:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-framework@tools.ietf.org, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Tue, 11 Jun 2013 22:35:11 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/eman/trac/ticket/35#comment:1 Message-ID: <070.f88040b8992a442340816fff3413c175@trac.tools.ietf.org> References: <055.a739eed8fef5e361e6d012f61a6eb41c@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <055.a739eed8fef5e361e6d012f61a6eb41c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-framework@tools.ietf.org, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bclaise@cisco.com, bnordman@lbl.gov, brad.schoening@verizon.net, jparello@cisco.com, quittek@netlab.nec.de Resent-Message-Id: <20130611223518.F131C21F9A49@ietfa.amsl.com> Resent-Date: Tue, 11 Jun 2013 15:35:18 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #35: Clarify how relationship model and power interface model X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:35:19 -0000 #35: Clarify how relationship model and power interface model Comment (by n.brownlee@auckland.ac.nz): John will check that the text is now appropriate. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-eman- bnordman@lbl.gov | framework@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG | Resolution: Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Tue Jun 11 16:05:12 2013 Return-Path: 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 88BCF21F9A71 for ; Tue, 11 Jun 2013 16:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6ThekuqdwPtk for ; Tue, 11 Jun 2013 16:05:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 44C8E21F9A85 for ; Tue, 11 Jun 2013 16:05:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:60859 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UmXcZ-0006IB-Da; Wed, 12 Jun 2013 01:04:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Tue, 11 Jun 2013 23:04:59 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/eman/trac/ticket/4#comment:11 Message-ID: <079.612d417496c21aaeab8dab8b2482cbaa@trac.tools.ietf.org> References: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #4: Reorganise sections X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 23:05:12 -0000 #4: Reorganise sections Comment (by n.brownlee@auckland.ac.nz): John says he's made responses (in the latest Word version of the draft) to Juergen's comments. Everyone to review; if no problems raised we'll close this issue at our next meeting. -- ---------------------------------------+------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: all Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | ---------------------------------------+------------------------- Ticket URL: eman From blueroofmusic@gmail.com Tue Jun 11 17:18:04 2013 Return-Path: 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 298A721F9A83 for ; Tue, 11 Jun 2013 17:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.367 X-Spam-Level: * X-Spam-Status: No, score=1.367 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 RWQXNv8p0j+9 for ; Tue, 11 Jun 2013 17:17:48 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AD24721F8930 for ; Tue, 11 Jun 2013 17:17:48 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so3288682ief.12 for ; Tue, 11 Jun 2013 17:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iiBGKmW5lPjx0BpKlkSdNzb6e1RnIYcpH1/6n5CcnW4=; b=Sh1pqVILb/ayUJmBWMC41D/B6u9L4+m5lHP9S8dueex2aYY0/rc7Zq6dWJOcGpRllI xH+wU2L7ygkRBl3R7Iu18J1iNAJC/Vv0W6ZopT/zznPYB3ghV9B6nq5/3NwtwbNFdAa9 HFe1P1HnPxa8J/Uiwc4sO3GpcPZEtdUAFmAeFn3MrBX7bWFAMAF6Pwi/68PKjOMuoZb0 ezD31IhTbVk3xzvB736JEF5Qd8AWZXU8/Qu00jGR7vzzqfDLBCzsgaN2u6J/qaUq1jDv B7zpvrdbGAAnReATO9hvpPUrGDsk47qG+G75YxuUiehVJ4FLYKc9zhewcxUYMD3yqNND mfSw== MIME-Version: 1.0 X-Received: by 10.50.128.132 with SMTP id no4mr2191494igb.38.1370996268204; Tue, 11 Jun 2013 17:17:48 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Tue, 11 Jun 2013 17:17:48 -0700 (PDT) In-Reply-To: <51B7A0AA.4080902@auckland.ac.nz> References: <51B7A0AA.4080902@auckland.ac.nz> Date: Tue, 11 Jun 2013 20:17:48 -0400 Message-ID: From: Ira McDonald To: Nevil Brownlee , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b10cee18e2a1804dee9f163 Cc: eman mailing list Subject: Re: [eman] Please add PWG power states to EMAN Framework X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 00:18:04 -0000 --047d7b10cee18e2a1804dee9f163 Content-Type: text/plain; charset=ISO-8859-1 Hi Nevil, We added the standard-named vendor extension sub-states under pressure from some of the printer vendors. But it's unlikely that printer vendors will ever register their own extension states with IANA - most of them don't currently publicly disclose much at all about their SNMP implementations (even their list of IETF and PWG MIB modules). I suggest not registering the PWG power states *at all* and just letting the printer vendors use the standard DMTF power states - which they have to do anyway for compatibility with DMTF CIM based management protocols and we standardized on this "folding" in the PWG Power Model and MIB. Cheers, - Ira (editor of PWG Imaging System Power MIB) 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/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 Tue, Jun 11, 2013 at 6:11 PM, Nevil Brownlee wrote: > > Hi Ira: > > Following up on your email dated 29 May, we've discussed the > PWG power states, and are happy to add them into the EMAN Framework's > Power State Sets. > > However, looking at the PWG states, we feel it's not a good idea > to have little subsets for particular vendors as part of the PWG > state set. That's mostly because it won't scale to a large number > of vendors. From an IANA point of view, it would be better to > have a separate IANA registry for Vendor-specific power states - > that way, when a new vendor needs particular states they could > simply ask IANA to add them to that registry. > > For now, we see three possible ways forward: > 1. Add PWG's power states, leaving out its vendor-specific > states. > 2. Leave the PWG states out of the EMAN power states for now; > they could be added later by asking IANA to register them > (they'd probably be subject to Expert review at that point). > 3. Discuss having a Vendor-specific Power States Registry with IANA. > > Would you please consider these possibilities, and let me know > which you'd like us to proceed with. Speaking only for myself, > I suggest that the question is "how important is it for PWG to > have vendor-specific power states?" > > Cheers, Nevil (EMAN co-chair) > > > > On 29/05/13 10:31 AM, Ira McDonald wrote: > >> Hi, >> >> I understand that the EMAN Framework document >> will request IANA to create some initial sets of power >> states. We would like this to include the PWG's power >> state set for imaging devices. That can be found at >> the following link and the states (and numeric codes) >> from that are listed below. >> >> The stable reference for IEEE-ISTO PWG power state >> names and numeric values is the PWG Imaging System >> Power MIB (PWG 5106.5-2011) archived at: >> >> ftp://ftp.pwg.org/pub/pwg/**candidates/cs-wimspowermib10-** >> 20110214-5106.5.mib >> >> On line 50 is the PowPowerStateTC definition, which uses >> the DMTF CIM power states multiplied by 10 w/ inserted >> vendor sub-states for a few stable (non-transient) states, >> as follows: >> >> PowPowerStateTC ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "The power state of this component (System or Subunit). >> >> Usage: Vendor extensions allowed ONLY for primary power states >> (on, standby, suspend, hibernate, and offSoft). Vendor >> extensions are intentionally not defined for reset or >> interrupts." >> REFERENCE >> "Table 3 in section 7.3 in DMTF CIM Power Profile (DSP 1027)." >> SYNTAX INTEGER { >> other(1), >> -- DO NOT USE >> unknown(2), -- initial default ONLY >> on(20), -- On - fully operational >> onVendor1(21), >> onVendor2(22), >> onVendor3(23), >> onVendor4(24), >> onVendor5(25), >> standby(30), -- Standby - light sleep >> standbyVendor1(31), >> standbyVendor2(32), >> standbyVendor3(33), >> standbyVendor4(34), >> standbyVendor5(35), >> suspend(40), -- Suspend - deep sleep >> suspendVendor1(41), >> suspendVendor2(42), >> suspendVendor3(43), >> suspendVendor4(44), >> suspendVendor5(45), >> resetSoft(50), -- Reset - soft reset >> offHard(60), -- Off Hard - no power consumed >> hibernate(70), -- Hibernate - context save, off >> hibernateVendor1(71), >> hibernateVendor2(72), >> hibernateVendor3(73), >> hibernateVendor4(74), >> hibernateVendor5(75), >> offSoft(80), -- Off Soft - w/ auxiliary power >> offSoftVendor1(81), >> offSoftVendor2(82), >> offSoftVendor3(83), >> offSoftVendor4(84), >> offSoftVendor5(85), >> resetHard(90), -- hard off, power on >> resetMBR(100), -- Master Bus Reset >> resetNMI(110), -- Non-Maskable Interrupt >> offSoftGraceful(120), -- orderley shutdown, soft off >> offHardGraceful(130), -- orderly shutdown, hard off >> resetMBRGraceful(140), -- orderly shutdown, MBR reset >> resetSoftGraceful(150), -- orderly shutdown, soft reset >> resetHardGraceful(160), -- orderly shutdown, hard reset >> resetINIT(170), -- Diagnostic Interrupt (INIT) >> notApplicable(180), >> noChange(190) >> } >> >> Thanks, >> - Ira (editor of PWG Power MIB and PWG Secretary). >> >> >> 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/**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 >> >> >> >> ______________________________**_________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/**listinfo/eman >> >> > > -- > ------------------------------**------------------------------**--------- > Nevil Brownlee Computer Science Department > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > --047d7b10cee18e2a1804dee9f163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Nevil,
=
We added the standard-named vendor extension sub-states under pre= ssure
from some of the printer vendors.=A0

But it's un= likely that printer vendors will ever register their own extension states <= br> with IANA - most of them don't currently publicly disclose much at all = about their
SNMP implementations (even their list of IETF and PWG MIB m= odules).

I suggest not registering the PWG p= ower states *at all* and just letting the
printer vendors use the standard DMTF power states - which they have = to
do anyway for compatibility with DMTF CIM based management prot= ocols
and we standardized on this "folding" in the = PWG Power Model and MIB.

Cheers,
- Ira (editor of PWG Imaging System Po= wer MIB)



Ira McDonald (Musician / Software Architect)
Chair - L= inux 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://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434



On Tue, Jun 11, 2013 at 6:11 PM, Nevil B= rownlee <n.brownlee@auckland.ac.nz> wrote:

Hi Ira:

Following up on your email dated 29 May, we've discussed the
PWG power states, and are happy to add them into the EMAN Framework's Power State Sets.

However, looking at the PWG states, we feel it's not a good idea
to have little subsets for particular vendors as part of the PWG
state set. =A0That's mostly because it won't scale to a large numbe= r
of vendors. =A0From an IANA point of view, it would be better to
have a separate IANA registry for Vendor-specific power states -
that way, when a new vendor needs particular states they could
simply ask IANA to add them to that registry.

For now, we see three possible ways forward:
1. Add PWG's power states, leaving out its vendor-specific
=A0 =A0states.
2. Leave the PWG states out of the EMAN power states for now;
=A0 =A0they could be added later by asking IANA to register them
=A0 =A0(they'd probably be subject to Expert review at that point).
3. Discuss having a Vendor-specific Power States Registry with IANA.

Would you please consider these possibilities, and let me know
which you'd like us to proceed with. =A0Speaking only for myself,
I suggest that the question is "how important is it for PWG to
have vendor-specific power states?"

Cheers, Nevil (EMAN co-chair)



On 29/05/13 10:31 AM, Ira McDonald wrote:
Hi,

I understand that the EMAN Framework document
will request IANA to create some initial sets of power
states. =A0We would like this to include the PWG's power
state set for imaging devices. =A0That can be found at
the following link and the states (and numeric codes)
from that are listed below.

The stable reference for IEEE-ISTO PWG power state
names and numeric values is the PWG Imaging System
Power MIB (PWG 5106.5-2011) archived at:

ftp://ftp.pwg.org/pub/pwg/candidates/c= s-wimspowermib10-20110214-5106.5.mib

On line 50 is the PowPowerStateTC definition, which uses
the DMTF CIM power states multiplied by 10 w/ inserted
vendor sub-states for a few stable (non-transient) states,
as follows:

PowPowerStateTC ::=3D TEXTUAL-CONVENTION
=A0 =A0 =A0STATUS =A0 =A0 =A0current
=A0 =A0 =A0DESCRIPTION
=A0 =A0 =A0 =A0 =A0"The power state of this component (System or Subun= it).

=A0 =A0 =A0 =A0 =A0Usage: =A0Vendor extensions allowed ONLY for primary pow= er states
=A0 =A0 =A0 =A0 =A0(on, standby, suspend, hibernate, and offSoft). =A0Vendo= r
=A0 =A0 =A0 =A0 =A0extensions are intentionally not defined for reset or =A0 =A0 =A0 =A0 =A0interrupts."
=A0 =A0 =A0REFERENCE
=A0 =A0 =A0 =A0 =A0"Table 3 in section 7.3 in DMTF CIM Power Profile (= DSP 1027)."
=A0 =A0 =A0SYNTAX =A0 =A0 =A0INTEGER {
=A0 =A0 =A0 =A0 =A0other(1),
=A0 =A0-- DO NOT USE
=A0 =A0 =A0 =A0 =A0unknown(2), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- i= nitial default ONLY
=A0 =A0 =A0 =A0 =A0on(20), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = -- On - fully operational
=A0 =A0 =A0 =A0 =A0onVendor1(21),
=A0 =A0 =A0 =A0 =A0onVendor2(22),
=A0 =A0 =A0 =A0 =A0onVendor3(23),
=A0 =A0 =A0 =A0 =A0onVendor4(24),
=A0 =A0 =A0 =A0 =A0onVendor5(25),
=A0 =A0 =A0 =A0 =A0standby(30), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- S= tandby - light sleep
=A0 =A0 =A0 =A0 =A0standbyVendor1(31),
=A0 =A0 =A0 =A0 =A0standbyVendor2(32),
=A0 =A0 =A0 =A0 =A0standbyVendor3(33),
=A0 =A0 =A0 =A0 =A0standbyVendor4(34),
=A0 =A0 =A0 =A0 =A0standbyVendor5(35),
=A0 =A0 =A0 =A0 =A0suspend(40), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- S= uspend - deep sleep
=A0 =A0 =A0 =A0 =A0suspendVendor1(41),
=A0 =A0 =A0 =A0 =A0suspendVendor2(42),
=A0 =A0 =A0 =A0 =A0suspendVendor3(43),
=A0 =A0 =A0 =A0 =A0suspendVendor4(44),
=A0 =A0 =A0 =A0 =A0suspendVendor5(45),
=A0 =A0 =A0 =A0 =A0resetSoft(50), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Res= et - soft reset
=A0 =A0 =A0 =A0 =A0offHard(60), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- O= ff Hard - no power consumed
=A0 =A0 =A0 =A0 =A0hibernate(70), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Hib= ernate - context save, off
=A0 =A0 =A0 =A0 =A0hibernateVendor1(71),
=A0 =A0 =A0 =A0 =A0hibernateVendor2(72),
=A0 =A0 =A0 =A0 =A0hibernateVendor3(73),
=A0 =A0 =A0 =A0 =A0hibernateVendor4(74),
=A0 =A0 =A0 =A0 =A0hibernateVendor5(75),
=A0 =A0 =A0 =A0 =A0offSoft(80), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- O= ff Soft - w/ auxiliary power
=A0 =A0 =A0 =A0 =A0offSoftVendor1(81),
=A0 =A0 =A0 =A0 =A0offSoftVendor2(82),
=A0 =A0 =A0 =A0 =A0offSoftVendor3(83),
=A0 =A0 =A0 =A0 =A0offSoftVendor4(84),
=A0 =A0 =A0 =A0 =A0offSoftVendor5(85),
=A0 =A0 =A0 =A0 =A0resetHard(90), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- har= d off, power on
=A0 =A0 =A0 =A0 =A0resetMBR(100), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mas= ter Bus Reset
=A0 =A0 =A0 =A0 =A0resetNMI(110), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Non= -Maskable Interrupt
=A0 =A0 =A0 =A0 =A0offSoftGraceful(120), =A0 =A0 =A0 =A0 =A0 -- orderley sh= utdown, soft off
=A0 =A0 =A0 =A0 =A0offHardGraceful(130), =A0 =A0 =A0 =A0 =A0 -- orderly shu= tdown, hard off
=A0 =A0 =A0 =A0 =A0resetMBRGraceful(140), =A0 =A0 =A0 =A0 =A0-- orderly shu= tdown, MBR reset
=A0 =A0 =A0 =A0 =A0resetSoftGraceful(150), =A0 =A0 =A0 =A0 -- orderly shutd= own, soft reset
=A0 =A0 =A0 =A0 =A0resetHardGraceful(160), =A0 =A0 =A0 =A0 -- orderly shutd= own, hard reset
=A0 =A0 =A0 =A0 =A0resetINIT(170), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Diagn= ostic Interrupt (INIT)
=A0 =A0 =A0 =A0 =A0notApplicable(180),
=A0 =A0 =A0 =A0 =A0noChange(190)
=A0 =A0 =A0}

Thanks,
- Ira (editor of PWG Power MIB and PWG Secretary).


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
ht= tp://sites.google.com/site/blueroofmusic
htt= p://sites.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter =A0579 Park Place =A0Saline, MI =A048176 =A0734-944-0094
Summer =A0PO Box 221 =A0Grand Marais, MI 49839 =A0906-494-2434



_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
-------------------------------------------------------------= --------
=A0Nevil Brownlee =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Comput= er Science Department
=A0Phone: +64 9 373 7599 x88941 =A0 =A0 =A0 =A0 =A0 =A0 Th= e University of Auckland
=A0FAX: +64 9 373 7453 =A0 Private Bag 92019, Auckland 1142, New Ze= aland

--047d7b10cee18e2a1804dee9f163-- From joelja@bogus.com Wed Jun 12 07:51:27 2013 Return-Path: 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 69DB721F9C41 for ; Wed, 12 Jun 2013 07:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 JyY42dapr86V for ; Wed, 12 Jun 2013 07:51:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 21DE221F9B9A for ; Wed, 12 Jun 2013 07:51:25 -0700 (PDT) Received: from wifi-216-68.mtg.afnog.org (wifi-216-68.mtg.afnog.org [196.200.216.68]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5CEpKR7056377 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 12 Jun 2013 14:51:24 GMT (envelope-from joelja@bogus.com) Message-ID: <51B88AE9.8040105@bogus.com> Date: Wed, 12 Jun 2013 16:51:21 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 12 Jun 2013 14:51:25 +0000 (UTC) Subject: [eman] Greetings eman. X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:51:27 -0000 Benoit and I discussed who should be a responsible AD for the working group and have decided that given his involvement as an author that it's probably appropriate for me to take it on. We've been working on the WG oversight activity since I was installed as Ron's successor. thanks joel From jparello@cisco.com Wed Jun 12 11:06:39 2013 Return-Path: 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 A459511E80BA for ; Wed, 12 Jun 2013 11:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 eX8Os-ekrd-t for ; Wed, 12 Jun 2013 11:06:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9645F11E80F0 for ; Wed, 12 Jun 2013 11:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=619; q=dns/txt; s=iport; t=1371060384; x=1372269984; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CxFVifGK4lvMOIqtA741sciv8wRmIvsboaz2ePlfG44=; b=eyveOUbsi70DCVyimCn/MrbyqZu+UvxzEVFbribUEKWshSKYOzJkdNzc 0DzIYBnnxijZj/+0U5iLE8864lJrsI2r/sK0mjKkZK/5QFPYetLp6nSHu VoQ7k9rMZWQMCJY7sFkZ9Z6HHBpGA3rgRo2clQWHPPV1iqGUo7ZnYp84j 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFAGq3uFGtJV2b/2dsb2JhbABbgwkwgna8HIEDFnSCIwEBAQMBAQEBNzQLBQsCAQg2ECcLJQIEDgWICAYMun4EjxAzB4J/YQOXQJFCgw8 X-IronPort-AV: E=Sophos;i="4.87,853,1363132800"; d="scan'208";a="221807811" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jun 2013 18:06:09 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5CI69vC027231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 18:06:09 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.232]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 13:06:09 -0500 From: "John Parello (jparello)" To: joel jaeggli Thread-Topic: [eman] Greetings eman. Thread-Index: AQHOZ3xVDKs1+T9cNEODsG+CSQAPYJkyYA1I Date: Wed, 12 Jun 2013 18:06:07 +0000 Message-ID: <93EF8132-DACF-48B6-AB72-CD97738D0F3E@cisco.com> References: <51B88AE9.8040105@bogus.com> In-Reply-To: <51B88AE9.8040105@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] Greetings eman. X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:06:39 -0000 Hi Joel, Welcome! Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Jun 12, 2013, at 7:51 AM, "joel jaeggli" wrote: > Benoit and I discussed who should be a responsible AD for the working gro= up and have decided that given his involvement as an author that it's prob= ably appropriate for me to take it on. We've been working on the WG oversig= ht activity since I was installed as Ron's successor. >=20 > thanks > joel > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Thu Jun 13 11:53:23 2013 Return-Path: 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 227A921F9A2B for ; Thu, 13 Jun 2013 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.396 X-Spam-Level: X-Spam-Status: No, score=-9.396 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_HI=-8] 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 jLvDhRyGKctY for ; Thu, 13 Jun 2013 11:53:19 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 837A721F9A26 for ; Thu, 13 Jun 2013 11:53:18 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5DIr9su008601; Thu, 13 Jun 2013 20:53:10 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5DIqLJI016946; Thu, 13 Jun 2013 20:52:31 +0200 (CEST) Message-ID: <51BA14E5.5050100@cisco.com> Date: Thu, 13 Jun 2013 20:52:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ira McDonald References: <51B7A0AA.4080902@auckland.ac.nz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000901070203060901000301" Cc: eman mailing list Subject: Re: [eman] Please add PWG power states to EMAN Framework X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 18:53:23 -0000 This is a multi-part message in MIME format. --------------000901070203060901000301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ira, That makes sense. Btw, they could still do later on. The EMAN framework IANA considerations section will contain the guidelines on how to do it. Regards, Benoit > Hi Nevil, > > We added the standard-named vendor extension sub-states under pressure > from some of the printer vendors. > > But it's unlikely that printer vendors will ever register their own > extension states > with IANA - most of them don't currently publicly disclose much at all > about their > SNMP implementations (even their list of IETF and PWG MIB modules). > > I suggest not registering the PWG power states *at all* and just > letting the > printer vendors use the standard DMTF power states - which they have to > do anyway for compatibility with DMTF CIM based management protocols > and we standardized on this "folding" in the PWG Power Model and MIB. > > Cheers, > - Ira (editor of PWG Imaging System Power MIB) > > > > 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/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 Tue, Jun 11, 2013 at 6:11 PM, Nevil Brownlee > > wrote: > > > Hi Ira: > > Following up on your email dated 29 May, we've discussed the > PWG power states, and are happy to add them into the EMAN Framework's > Power State Sets. > > However, looking at the PWG states, we feel it's not a good idea > to have little subsets for particular vendors as part of the PWG > state set. That's mostly because it won't scale to a large number > of vendors. From an IANA point of view, it would be better to > have a separate IANA registry for Vendor-specific power states - > that way, when a new vendor needs particular states they could > simply ask IANA to add them to that registry. > > For now, we see three possible ways forward: > 1. Add PWG's power states, leaving out its vendor-specific > states. > 2. Leave the PWG states out of the EMAN power states for now; > they could be added later by asking IANA to register them > (they'd probably be subject to Expert review at that point). > 3. Discuss having a Vendor-specific Power States Registry with IANA. > > Would you please consider these possibilities, and let me know > which you'd like us to proceed with. Speaking only for myself, > I suggest that the question is "how important is it for PWG to > have vendor-specific power states?" > > Cheers, Nevil (EMAN co-chair) > > > > On 29/05/13 10:31 AM, Ira McDonald wrote: > > Hi, > > I understand that the EMAN Framework document > will request IANA to create some initial sets of power > states. We would like this to include the PWG's power > state set for imaging devices. That can be found at > the following link and the states (and numeric codes) > from that are listed below. > > The stable reference for IEEE-ISTO PWG power state > names and numeric values is the PWG Imaging System > Power MIB (PWG 5106.5-2011) archived at: > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib > > On line 50 is the PowPowerStateTC definition, which uses > the DMTF CIM power states multiplied by 10 w/ inserted > vendor sub-states for a few stable (non-transient) states, > as follows: > > PowPowerStateTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The power state of this component (System or Subunit). > > Usage: Vendor extensions allowed ONLY for primary > power states > (on, standby, suspend, hibernate, and offSoft). Vendor > extensions are intentionally not defined for reset or > interrupts." > REFERENCE > "Table 3 in section 7.3 in DMTF CIM Power Profile > (DSP 1027)." > SYNTAX INTEGER { > other(1), > -- DO NOT USE > unknown(2), -- initial default ONLY > on(20), -- On - fully operational > onVendor1(21), > onVendor2(22), > onVendor3(23), > onVendor4(24), > onVendor5(25), > standby(30), -- Standby - light sleep > standbyVendor1(31), > standbyVendor2(32), > standbyVendor3(33), > standbyVendor4(34), > standbyVendor5(35), > suspend(40), -- Suspend - deep sleep > suspendVendor1(41), > suspendVendor2(42), > suspendVendor3(43), > suspendVendor4(44), > suspendVendor5(45), > resetSoft(50), -- Reset - soft reset > offHard(60), -- Off Hard - no > power consumed > hibernate(70), -- Hibernate - > context save, off > hibernateVendor1(71), > hibernateVendor2(72), > hibernateVendor3(73), > hibernateVendor4(74), > hibernateVendor5(75), > offSoft(80), -- Off Soft - w/ > auxiliary power > offSoftVendor1(81), > offSoftVendor2(82), > offSoftVendor3(83), > offSoftVendor4(84), > offSoftVendor5(85), > resetHard(90), -- hard off, power on > resetMBR(100), -- Master Bus Reset > resetNMI(110), -- Non-Maskable Interrupt > offSoftGraceful(120), -- orderley shutdown, > soft off > offHardGraceful(130), -- orderly shutdown, > hard off > resetMBRGraceful(140), -- orderly shutdown, > MBR reset > resetSoftGraceful(150), -- orderly shutdown, > soft reset > resetHardGraceful(160), -- orderly shutdown, > hard reset > resetINIT(170), -- Diagnostic > Interrupt (INIT) > notApplicable(180), > noChange(190) > } > > Thanks, > - Ira (editor of PWG Power MIB and PWG Secretary). > > > 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/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 > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department > Phone: +64 9 373 7599 x88941 > The University > of Auckland > FAX: +64 9 373 7453 Private Bag > 92019, Auckland 1142, New Zealand > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------000901070203060901000301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ira,

That makes sense.
Btw, they could still do later on. The EMAN framework IANA considerations section will contain the guidelines on how to do it.

Regards, Benoit
Hi Nevil,

We added the standard-named vendor extension sub-states under pressure
from some of the printer vendors. 

But it's unlikely that printer vendors will ever register their own extension states
with IANA - most of them don't currently publicly disclose much at all about their
SNMP implementations (even their list of IETF and PWG MIB modules).

I suggest not registering the PWG power states *at all* and just letting the
printer vendors use the standard DMTF power states - which they have to
do anyway for compatibility with DMTF CIM based management protocols
and we standardized on this "folding" in the PWG Power Model and MIB.

Cheers,
- Ira (editor of PWG Imaging System Power MIB)



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/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 Tue, Jun 11, 2013 at 6:11 PM, Nevil Brownlee <n.brownlee@auckland.ac.nz> wrote:

Hi Ira:

Following up on your email dated 29 May, we've discussed the
PWG power states, and are happy to add them into the EMAN Framework's
Power State Sets.

However, looking at the PWG states, we feel it's not a good idea
to have little subsets for particular vendors as part of the PWG
state set.  That's mostly because it won't scale to a large number
of vendors.  From an IANA point of view, it would be better to
have a separate IANA registry for Vendor-specific power states -
that way, when a new vendor needs particular states they could
simply ask IANA to add them to that registry.

For now, we see three possible ways forward:
1. Add PWG's power states, leaving out its vendor-specific
   states.
2. Leave the PWG states out of the EMAN power states for now;
   they could be added later by asking IANA to register them
   (they'd probably be subject to Expert review at that point).
3. Discuss having a Vendor-specific Power States Registry with IANA.

Would you please consider these possibilities, and let me know
which you'd like us to proceed with.  Speaking only for myself,
I suggest that the question is "how important is it for PWG to
have vendor-specific power states?"

Cheers, Nevil (EMAN co-chair)



On 29/05/13 10:31 AM, Ira McDonald wrote:
Hi,

I understand that the EMAN Framework document
will request IANA to create some initial sets of power
states.  We would like this to include the PWG's power
state set for imaging devices.  That can be found at
the following link and the states (and numeric codes)
from that are listed below.

The stable reference for IEEE-ISTO PWG power state
names and numeric values is the PWG Imaging System
Power MIB (PWG 5106.5-2011) archived at:

ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib

On line 50 is the PowPowerStateTC definition, which uses
the DMTF CIM power states multiplied by 10 w/ inserted
vendor sub-states for a few stable (non-transient) states,
as follows:

PowPowerStateTC ::= TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION
         "The power state of this component (System or Subunit).

         Usage:  Vendor extensions allowed ONLY for primary power states
         (on, standby, suspend, hibernate, and offSoft).  Vendor
         extensions are intentionally not defined for reset or
         interrupts."
     REFERENCE
         "Table 3 in section 7.3 in DMTF CIM Power Profile (DSP 1027)."
     SYNTAX      INTEGER {
         other(1),
   -- DO NOT USE
         unknown(2),                     -- initial default ONLY
         on(20),                         -- On - fully operational
         onVendor1(21),
         onVendor2(22),
         onVendor3(23),
         onVendor4(24),
         onVendor5(25),
         standby(30),                    -- Standby - light sleep
         standbyVendor1(31),
         standbyVendor2(32),
         standbyVendor3(33),
         standbyVendor4(34),
         standbyVendor5(35),
         suspend(40),                    -- Suspend - deep sleep
         suspendVendor1(41),
         suspendVendor2(42),
         suspendVendor3(43),
         suspendVendor4(44),
         suspendVendor5(45),
         resetSoft(50),                  -- Reset - soft reset
         offHard(60),                    -- Off Hard - no power consumed
         hibernate(70),                  -- Hibernate - context save, off
         hibernateVendor1(71),
         hibernateVendor2(72),
         hibernateVendor3(73),
         hibernateVendor4(74),
         hibernateVendor5(75),
         offSoft(80),                    -- Off Soft - w/ auxiliary power
         offSoftVendor1(81),
         offSoftVendor2(82),
         offSoftVendor3(83),
         offSoftVendor4(84),
         offSoftVendor5(85),
         resetHard(90),                  -- hard off, power on
         resetMBR(100),                  -- Master Bus Reset
         resetNMI(110),                  -- Non-Maskable Interrupt
         offSoftGraceful(120),           -- orderley shutdown, soft off
         offHardGraceful(130),           -- orderly shutdown, hard off
         resetMBRGraceful(140),          -- orderly shutdown, MBR reset
         resetSoftGraceful(150),         -- orderly shutdown, soft reset
         resetHardGraceful(160),         -- orderly shutdown, hard reset
         resetINIT(170),                 -- Diagnostic Interrupt (INIT)
         notApplicable(180),
         noChange(190)
     }

Thanks,
- Ira (editor of PWG Power MIB and PWG Secretary).


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/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



_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman



--
---------------------------------------------------------------------
 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand



_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

--------------000901070203060901000301-- From bnordman@lbl.gov Mon Jun 17 12:33:36 2013 Return-Path: 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 30D8711E80A2 for ; Mon, 17 Jun 2013 12:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Xh0a9HM2ntL0 for ; Mon, 17 Jun 2013 12:33:31 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06B21E805E for ; Mon, 17 Jun 2013 12:33:31 -0700 (PDT) X-Ironport-SBRS: 4.8 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjICAIxjv1HRVYCwlGdsb2JhbABYA4JFdUmtCgGJNog8dggWDgEBAQEHCwsJEiqDQgddEgEFASITFId6mWSCfp00jX+BOCiDTwOJII4hgSmONRYphFUc X-IronPort-AV: E=Sophos;i="4.87,882,1363158000"; d="scan'208";a="20438746" Received: from mail-ve0-f176.google.com ([209.85.128.176]) by fe1.lbl.gov with ESMTP; 17 Jun 2013 12:33:29 -0700 Received: by mail-ve0-f176.google.com with SMTP id c13so2434412vea.21 for ; Mon, 17 Jun 2013 12:33:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=LxYfAKNocSPENJeJstMQLCDyacWgPi6UDWbQ9hAHuA4=; b=OXj+jndFYgFOu7m8KCB/7zIh+ytaazbkoQSAica2h51dX7UWMoYOhw9AiZxe5Jo5zu WdsQO9DAlTz4k+OyeKg4EkoRd+P4Y5R87dm8jWDMSgSAPYCRfGyuUtaYWyNP3Uwtkukc fvDpuqKTRd/fivPChn3f8AR1zX/FI6oUz6+qvqIfKMghDs3s5KXm+teK8dfN1bWqVT+Q d3Vix8VTg9D09k7r0i3zFsUfVWLkTExnUNQzIlyAJKNpY0A7YKttaTgOh+GnkWd3uIIv Sf4COfex1jdjTfM6kL9kvSelvKyJSoIKUy88FnKyEha9XthJW6TQRMpaXTNsQ4CJidKE keVQ== X-Received: by 10.220.215.73 with SMTP id hd9mr660187vcb.19.1371497609706; Mon, 17 Jun 2013 12:33:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.215.73 with SMTP id hd9mr660185vcb.19.1371497609567; Mon, 17 Jun 2013 12:33:29 -0700 (PDT) Received: by 10.58.213.138 with HTTP; Mon, 17 Jun 2013 12:33:29 -0700 (PDT) Date: Mon, 17 Jun 2013 12:33:29 -0700 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=bcaec54ee374d42fe304df5eab70 X-Gm-Message-State: ALoCoQkQ+T35t3VhLao0mIUmeao2sqMWB79kODgMIHCB9tBV25y8g7iQ6e4NfQr5qZGpjA3jssuWGvo1124vklnw9vRN1ioBIbplhfy5Ijo0NYzlBT9OvuRPXADKGoqtfJpdy9enXUG+ Subject: [eman] EMAN co-chair update X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:33:36 -0000 --bcaec54ee374d42fe304df5eab70 Content-Type: text/plain; charset=ISO-8859-1 Greetings EMAN-- I am stepping down as EMAN WG co-chair, and withdrawing as a co-author of the Framework draft. This does not indicate that I will be less a participant in EMAN - to the contrary, it will enable me to be active in ways that might be problematic being also co-chair. I think this will help move the process forward more quickly and productively to a good conclusion. The process remains in good hands with Nevil, Joel, and Benoit. As the only "energy" person significantly involved in the process, I appreciate the IETF (and in particular Dan) reaching out to my community to invite me in as co-chair nearly three years ago. As we deal with a topic that spans networking and energy, I have tried to represent the energy perspective part, in particular with: draft-norwin-energy-consider-02 draft-nordman-eman-energy-perspective-01 draft-nordman-classification-00 draft-quittek-eman-reference-model-03 We have a solid foundation now: Two solid final documents (Entity MIB v4 and the Requirements), and two that are ready to be final (Battery MIB and Applicability). In November 2011 in Taipei, we agreed to try to merge the principles from the Reference Model into the Framework and so I joined as a co-author. The five of us plus Nevil have spent a lot of time and effort over the last 18 months to try to reconcile the differences in the two approaches and to address my many concerns with the document. Had it worked, a joint effort would have been the best outcome. While some progress has been made, at this point it does not seem likely that many of the many remaining issues can be resolved. I look forward to the coming months and contributing to EMAN process as it moves forward. Thank you, --Bruce -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec54ee374d42fe304df5eab70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Greetings EMAN--

=A0 I am stepping down as EMAN WG = co-chair, and withdrawing as a
co-author of the Framework draft.=A0 This= does not indicate that I
will be less a participant in EMAN - to the c= ontrary, it will
enable me to be active in ways that might be problematic being
also co-= chair.=A0 I think this will help move the process forward
more quickly = and productively to a good conclusion.=A0 The process
remains in good ha= nds with Nevil, Joel, and Benoit.

=A0 As the only "energy" person significantly involved in the= process,
I appreciate the IETF (and in particular Dan) reaching out to = my
community to invite me in as co-chair nearly three years ago.
As w= e deal with a topic that spans networking and energy, I have
tried to represent the energy perspective part, in particular with:
=A0 = draft-norwin-energy-consider-02
=A0 draft-nordman-eman-energy-perspectiv= e-01
=A0 draft-nordman-classification-00
=A0 draft-quittek-eman-refer= ence-model-03
=A0
=A0 We have a solid foundation now: Two solid final documents
(= Entity MIB v4 and the Requirements), and two that are ready to be
final = (Battery MIB and Applicability).

=A0 In November 2011 in Taipei, we = agreed to try to merge the principles
from the Reference Model into the Framework and so I joined as a
co-auth= or.=A0 The five of us plus Nevil have spent a lot of time and
effort ove= r the last 18 months to try to reconcile the differences
in the two app= roaches and to address my many concerns with the document.=A0
Had it worked, a joint effort would have been the best outcome.=A0
Whil= e some progress has been made, at this point it does not seem
likely th= at many of the many remaining issues can be resolved.=A0

I look for= ward to the coming months and contributing to EMAN process
as it moves forward.=A0

Thank you,

--Bruce



--
Bruce Nordman
Lawrence Berkeley National Laboratorynordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--bcaec54ee374d42fe304df5eab70-- From joelja@bogus.com Mon Jun 17 14:26:52 2013 Return-Path: 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 07D0B21F9D72 for ; Mon, 17 Jun 2013 14:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 S7im53MMo21K for ; Mon, 17 Jun 2013 14:26:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EC21E21F9D8C for ; Mon, 17 Jun 2013 14:26:48 -0700 (PDT) Received: from joels-MacBook-Air.local ([41.223.119.26]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5HLQfbQ035406 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 17 Jun 2013 21:26:46 GMT (envelope-from joelja@bogus.com) Message-ID: <51BF7F10.8020907@bogus.com> Date: Mon, 17 Jun 2013 23:26:40 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Bruce Nordman , eman mailing list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 17 Jun 2013 21:26:48 +0000 (UTC) Subject: Re: [eman] EMAN co-chair update X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 21:26:52 -0000 Bruce, I would like to again thank you for your service as EMAN co-chair. It's especially notable because you took it on as a relative newcomer to the IETF. You provided me with valuable advice, which I will no doubt be seeking again in the future. Regards joel On 6/17/13 9:33 PM, Bruce Nordman wrote: > Greetings EMAN-- > > I am stepping down as EMAN WG co-chair, and withdrawing as a > co-author of the Framework draft. This does not indicate that I > will be less a participant in EMAN - to the contrary, it will > enable me to be active in ways that might be problematic being > also co-chair. I think this will help move the process forward > more quickly and productively to a good conclusion. The process > remains in good hands with Nevil, Joel, and Benoit. > > As the only "energy" person significantly involved in the process, > I appreciate the IETF (and in particular Dan) reaching out to my > community to invite me in as co-chair nearly three years ago. > As we deal with a topic that spans networking and energy, I have > tried to represent the energy perspective part, in particular with: > draft-norwin-energy-consider-02 > draft-nordman-eman-energy-perspective-01 > draft-nordman-classification-00 > draft-quittek-eman-reference-model-03 > > We have a solid foundation now: Two solid final documents > (Entity MIB v4 and the Requirements), and two that are ready to be > final (Battery MIB and Applicability). > > In November 2011 in Taipei, we agreed to try to merge the principles > from the Reference Model into the Framework and so I joined as a > co-author. The five of us plus Nevil have spent a lot of time and > effort over the last 18 months to try to reconcile the differences > in the two approaches and to address my many concerns with the document. > Had it worked, a joint effort would have been the best outcome. > While some progress has been made, at this point it does not seem > likely that many of the many remaining issues can be resolved. > > I look forward to the coming months and contributing to EMAN process > as it moves forward. > > Thank you, > > --Bruce > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov * > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From n.brownlee@auckland.ac.nz Mon Jun 17 15:22:01 2013 Return-Path: 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 7D2D821F92E7 for ; Mon, 17 Jun 2013 15:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 oOicKzHlikt2 for ; Mon, 17 Jun 2013 15:21:57 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id A2BFF21F9E5E for ; Mon, 17 Jun 2013 15:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1371507712; x=1403043712; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j99OXHfVryFG0QojSE1sJwW3DwXsT54nP10ptpPTXI4=; b=TcyVJDT5AVFq7AuNdLUb7s9KH6fN1L3D1bDskbPSt9VYn+A0xvQiiXp6 uatS7w1ZcZe/ywEnFuH/S7iJfD4QvIM7AlXb2mAF4lWYFiSC0C5F4y9I/ enYM+x5wktuSEYo/Y3WKJ5/P/M5YgsTgckA9XxsL5/xBkSb3hO4bukVq3 A=; X-IronPort-AV: E=Sophos;i="4.87,884,1363086000"; d="scan'208";a="194495918" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 18 Jun 2013 10:21:30 +1200 Message-ID: <51BF8BEA.40709@auckland.ac.nz> Date: Tue, 18 Jun 2013 10:21:30 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bruce Nordman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] EMAN co-chair update X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 22:22:01 -0000 Hi Bruce: Thanks a lot for all your work in EMAN; I've enjoyed working with you. As a newcomer to energy management, I certainly learned a lot about it from all our interactions! Cheers, Nevil On 18/06/13 7:33 AM, Bruce Nordman wrote: > Greetings EMAN-- > > I am stepping down as EMAN WG co-chair, and withdrawing as a > co-author of the Framework draft. This does not indicate that I > will be less a participant in EMAN - to the contrary, it will > enable me to be active in ways that might be problematic being > also co-chair. I think this will help move the process forward > more quickly and productively to a good conclusion. The process > remains in good hands with Nevil, Joel, and Benoit. > > As the only "energy" person significantly involved in the process, > I appreciate the IETF (and in particular Dan) reaching out to my > community to invite me in as co-chair nearly three years ago. > As we deal with a topic that spans networking and energy, I have > tried to represent the energy perspective part, in particular with: > draft-norwin-energy-consider-02 > draft-nordman-eman-energy-perspective-01 > draft-nordman-classification-00 > draft-quittek-eman-reference-model-03 > > We have a solid foundation now: Two solid final documents > (Entity MIB v4 and the Requirements), and two that are ready to be > final (Battery MIB and Applicability). > > In November 2011 in Taipei, we agreed to try to merge the principles > from the Reference Model into the Framework and so I joined as a > co-author. The five of us plus Nevil have spent a lot of time and > effort over the last 18 months to try to reconcile the differences > in the two approaches and to address my many concerns with the document. > Had it worked, a joint effort would have been the best outcome. > While some progress has been made, at this point it does not seem > likely that many of the many remaining issues can be resolved. > > I look forward to the coming months and contributing to EMAN process > as it moves forward. > > Thank you, > > --Bruce > > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Tue Jun 18 01:06:38 2013 Return-Path: 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 41EEE21F9CFD for ; Tue, 18 Jun 2013 01:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ScsTRjRFetOs for ; Tue, 18 Jun 2013 01:06:34 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D95D121F9A03 for ; Tue, 18 Jun 2013 01:06:29 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5I86NbW026333; Tue, 18 Jun 2013 10:06:23 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5I85tW5016462; Tue, 18 Jun 2013 10:06:12 +0200 (CEST) Message-ID: <51C014E3.1030300@cisco.com> Date: Tue, 18 Jun 2013 10:05:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bruce Nordman References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000308070200000800080708" Cc: eman mailing list Subject: Re: [eman] EMAN co-chair update X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:06:38 -0000 This is a multi-part message in MIME format. --------------000308070200000800080708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Bruce for your 3 years of service. Much appreciated. Regards, Benoit > Greetings EMAN-- > > I am stepping down as EMAN WG co-chair, and withdrawing as a > co-author of the Framework draft. This does not indicate that I > will be less a participant in EMAN - to the contrary, it will > enable me to be active in ways that might be problematic being > also co-chair. I think this will help move the process forward > more quickly and productively to a good conclusion. The process > remains in good hands with Nevil, Joel, and Benoit. > > As the only "energy" person significantly involved in the process, > I appreciate the IETF (and in particular Dan) reaching out to my > community to invite me in as co-chair nearly three years ago. > As we deal with a topic that spans networking and energy, I have > tried to represent the energy perspective part, in particular with: > draft-norwin-energy-consider-02 > draft-nordman-eman-energy-perspective-01 > draft-nordman-classification-00 > draft-quittek-eman-reference-model-03 > > We have a solid foundation now: Two solid final documents > (Entity MIB v4 and the Requirements), and two that are ready to be > final (Battery MIB and Applicability). > > In November 2011 in Taipei, we agreed to try to merge the principles > from the Reference Model into the Framework and so I joined as a > co-author. The five of us plus Nevil have spent a lot of time and > effort over the last 18 months to try to reconcile the differences > in the two approaches and to address my many concerns with the document. > Had it worked, a joint effort would have been the best outcome. > While some progress has been made, at this point it does not seem > likely that many of the many remaining issues can be resolved. > > I look forward to the coming months and contributing to EMAN process > as it moves forward. > > Thank you, > > --Bruce > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov * > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------000308070200000800080708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks Bruce for your 3 years of service. Much appreciated.

Regards, Benoit
Greetings EMAN--

  I am stepping down as EMAN WG co-chair, and withdrawing as a
co-author of the Framework draft.  This does not indicate that I
will be less a participant in EMAN - to the contrary, it will
enable me to be active in ways that might be problematic being
also co-chair.  I think this will help move the process forward
more quickly and productively to a good conclusion.  The process
remains in good hands with Nevil, Joel, and Benoit.

  As the only "energy" person significantly involved in the process,
I appreciate the IETF (and in particular Dan) reaching out to my
community to invite me in as co-chair nearly three years ago.
As we deal with a topic that spans networking and energy, I have
tried to represent the energy perspective part, in particular with:
  draft-norwin-energy-consider-02
  draft-nordman-eman-energy-perspective-01
  draft-nordman-classification-00
  draft-quittek-eman-reference-model-03
 
  We have a solid foundation now: Two solid final documents
(Entity MIB v4 and the Requirements), and two that are ready to be
final (Battery MIB and Applicability).

  In November 2011 in Taipei, we agreed to try to merge the principles
from the Reference Model into the Framework and so I joined as a
co-author.  The five of us plus Nevil have spent a lot of time and
effort over the last 18 months to try to reconcile the differences
in the two approaches and to address my many concerns with the document. 
Had it worked, a joint effort would have been the best outcome. 
While some progress has been made, at this point it does not seem
likely that many of the many remaining issues can be resolved. 

I look forward to the coming months and contributing to EMAN process
as it moves forward. 

Thank you,

--Bruce



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943


_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

--------------000308070200000800080708-- From dromasca@avaya.com Tue Jun 18 01:58:20 2013 Return-Path: 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 3F46021F9A6E for ; Tue, 18 Jun 2013 01:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.483 X-Spam-Level: X-Spam-Status: No, score=-103.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 DhSwnZHR4pUv for ; Tue, 18 Jun 2013 01:58:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA221F9C3E for ; Tue, 18 Jun 2013 01:58:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAAH/ZlHGmAcF/2dsb2JhbABNA4JCIyE2uRYBiDGBBxZ0gh8BAQEBAxIbQRsCAQgNAQMEAQELHQcyFAkIAgQBEggMDodyAaBHjGeQJReNToEXIQURARGCT2EDmCOFBopogwuCKA X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208,217";a="15991168" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Jun 2013 04:58:13 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Jun 2013 04:56:18 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 10:58:12 +0200 From: "Romascanu, Dan (Dan)" To: Bruce Nordman , eman mailing list Thread-Topic: [eman] EMAN co-chair update Thread-Index: AQHOa5GSuS+QC34GdUOgsEfxzG4cd5k7LICg Date: Tue, 18 Jun 2013 08:58:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1A3A44@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1A3A44AZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [eman] EMAN co-chair update X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:58:20 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1A3A44AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Congratulations and thanks for your dedicated work as EMAN co-chair, good c= hance and success in the future work! Dan From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bru= ce Nordman Sent: Monday, June 17, 2013 10:33 PM To: eman mailing list Subject: [eman] EMAN co-chair update Greetings EMAN-- I am stepping down as EMAN WG co-chair, and withdrawing as a co-author of the Framework draft. This does not indicate that I will be less a participant in EMAN - to the contrary, it will enable me to be active in ways that might be problematic being also co-chair. I think this will help move the process forward more quickly and productively to a good conclusion. The process remains in good hands with Nevil, Joel, and Benoit. As the only "energy" person significantly involved in the process, I appreciate the IETF (and in particular Dan) reaching out to my community to invite me in as co-chair nearly three years ago. As we deal with a topic that spans networking and energy, I have tried to represent the energy perspective part, in particular with: draft-norwin-energy-consider-02 draft-nordman-eman-energy-perspective-01 draft-nordman-classification-00 draft-quittek-eman-reference-model-03 We have a solid foundation now: Two solid final documents (Entity MIB v4 and the Requirements), and two that are ready to be final (Battery MIB and Applicability). In November 2011 in Taipei, we agreed to try to merge the principles from the Reference Model into the Framework and so I joined as a co-author. The five of us plus Nevil have spent a lot of time and effort over the last 18 months to try to reconcile the differences in the two approaches and to address my many concerns with the document. Had it worked, a joint effort would have been the best outcome. While some progress has been made, at this point it does not seem likely that many of the many remaining issues can be resolved. I look forward to the coming months and contributing to EMAN process as it moves forward. Thank you, --Bruce -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_9904FB1B0159DA42B0B887B7FA8119CA1A3A44AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Congratulations and thank= s for your dedicated work as EMAN co-chair, good chance and success in the = future work!

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: eman-bou= nces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
Sent: Monday, June 17, 2013 10:33 PM
To: eman mailing list
Subject: [eman] EMAN co-chair update

 

Greetings EMAN--

  I am stepping down as EMAN WG co-chair, and withdrawing as a
co-author of the Framework draft.  This does not indicate that I
will be less a participant in EMAN - to the contrary, it will
enable me to be active in ways that might be problematic being
also co-chair.  I think this will help move the process forward
more quickly and productively to a good conclusion.  The process
remains in good hands with Nevil, Joel, and Benoit.

  As the only "energy" person significantly involved in the = process,
I appreciate the IETF (and in particular Dan) reaching out to my
community to invite me in as co-chair nearly three years ago.
As we deal with a topic that spans networking and energy, I have
tried to represent the energy perspective part, in particular with:
  draft-norwin-energy-consider-02
  draft-nordman-eman-energy-perspective-01
  draft-nordman-classification-00
  draft-quittek-eman-reference-model-03
 
  We have a solid foundation now: Two solid final documents
(Entity MIB v4 and the Requirements), and two that are ready to be
final (Battery MIB and Applicability).

  In November 2011 in Taipei, we agreed to try to merge the principles=
from the Reference Model into the Framework and so I joined as a
co-author.  The five of us plus Nevil have spent a lot of time and
effort over the last 18 months to try to reconcile the differences
in the two approaches and to address my many concerns with the document.&nb= sp;
Had it worked, a joint effort would have been the best outcome. 
While some progress has been made, at this point it does not seem
likely that many of the many remaining issues can be resolved. 

I look forward to the coming months and contributing to EMAN process
as it moves forward. 

Thank you,

--Bruce



--
Bruce Nordman
Lawrence Berkeley National Laboratory<= br> nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--_000_9904FB1B0159DA42B0B887B7FA8119CA1A3A44AZFFEXMB04globala_-- From B.Hedstrom@CableLabs.com Tue Jun 18 12:55:24 2013 Return-Path: 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 A487821F9A1F for ; Tue, 18 Jun 2013 12:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 4ux5gLopkv5Y for ; Tue, 18 Jun 2013 12:55:19 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9DD21F9A03 for ; Tue, 18 Jun 2013 12:55:19 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r5IJtH5X007084 for ; Tue, 18 Jun 2013 13:55:17 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 18 Jun 2013 13:55:17 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0123.003; Tue, 18 Jun 2013 13:55:17 -0600 From: Brian Hedstrom To: "eman@ietf.org" Thread-Topic: EMAN Applicability Statement Draft -02 review comments from SCTE meeting Thread-Index: AQHObF3AGdjpkcJD2Em+66R7aDPA5g== Date: Tue, 18 Jun 2013 19:55:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.253.129.78] Content-Type: multipart/alternative; boundary="_000_CDE6174224887bhedstromcablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [eman] EMAN Applicability Statement Draft -02 review comments from SCTE meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:55:24 -0000 --_000_CDE6174224887bhedstromcablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few months back I presented the EMAN Applicability Use Cases at the SCTE = SEMI meeting and received some feedback during the presentation. The items I would like to feed back to this team include: 1. What energy storage devices are IETF considering? Does IETF cover ge= nerators? 2. We would like to request IETF to create IETF "use case patterns" as a= matrix 3. Should IANA be listed in "Other" under Relationship of EMAN to other = Standards? 4. Should NEMA (instead of ANSI C12.20) be listed in "Other" and "Measur= ement" under Relationship of EMAN to other Standards? 5. Should IETF draft identify SCTE & APSIS? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com --_000_CDE6174224887bhedstromcablelabscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6D3C30ADF04C3D4EB6CBF79CE3089F8B@cablelabs.com> Content-Transfer-Encoding: quoted-printable
A few months back I presented the EMAN Applicability Use Cases at the SCTE = SEMI meeting and received some feedback during the presentation.
The items I would like to feed back to this team include:
  1. What energy storage devices are IETF considering?  Does IETF cover gen= erators?
  2. We would like to request IETF to create IETF "use case patterns" = as a matrix
  3. Should IANA be listed= in "Other" under Relationship of EMAN to other Standards?=
  4. Should NEMA (instead of ANSI C12= .20) be list= ed in "Other" and "Measurement" under Relationship of E= MAN to other Standards?
  5. Sh= ould IETF draft identify SCTE & APSIS?
Thanks,

Brian Hedstrom
Senior Architect, Business & Operational Support Systems
CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
Google+: brian.hedstrom
Skype IM: brian.hedstrom 
b.hedstrom@cablelabs.com=

Thread-Topic: [eman] EMAN Applicability Statement Draft -02 review comments from SCTE meeting Thread-Index: AQHObF3AGdjpkcJD2Em+66R7aDPA5pk+sfGA Date: Thu, 20 Jun 2013 13:49:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.247] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_CDE87F00B5E86bradscoraidcom_" MIME-Version: 1.0 Subject: Re: [eman] EMAN Applicability Statement Draft -02 review comments from SCTE meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:49:32 -0000 --_000_CDE87F00B5E86bradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, Thanks for your feedback. I have a few questions that to help clarify * We would like to request IETF to create IETF "use case patterns" as a= matrix * I'm not sure how this would work. Could you provide a little more = description of what this matrix would look like. Would it replace the use = case patterns or augment it? * Should NEMA (instead of ANSI C12.20) be listed in "Other" and "Measur= ement" under Relationship of EMAN to other Standards? * Lately I've seen 'ANSI C12.20' referred to as 'NEMA ANSI C12.20'. = Has ownership of the C12.20 standard shared or transferred? * Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Brian Hedstrom > Date: Tue, 18 Jun 2013 19:55:15 +0000 To: "eman@ietf.org" > Subject: [eman] EMAN Applicability Statement Draft -02 review comments from= SCTE meeting A few months back I presented the EMAN Applicability Use Cases at the SCTE = SEMI meeting and received some feedback during the presentation. The items I would like to feed back to this team include: 1. What energy storage devices are IETF considering? Does IETF cover ge= nerators? 2. We would like to request IETF to create IETF "use case patterns" as a= matrix 3. Should IANA be listed in "Other" under Relationship of EMAN to other = Standards? 4. Should NEMA (instead of ANSI C12.20) be listed in "Other" and "Measur= ement" under Relationship of EMAN to other Standards? 5. Should IETF draft identify SCTE & APSIS? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CDE87F00B5E86bradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Brian,

Thanks for your feedback.  I have a few questions that to help cl= arify
  • We would like to request IETF to create IETF "use case patterns" = as a matrix
    • I'm not sure how this would work. Could you provide a little more descripti= on of what this matrix would look like.  Would it replace the use case= patterns or augment it?
  • Should NEMA (instead of ANSI C12= .20) be list= ed in "Other" and "Measurement" under Relationship of E= MAN to other Standards?
    • Lately I've seen 'ANSI C12.20' referred to as 'NEMA ANSI C12.20'. &n= bsp;Has ownership of the C12.20 standard shared or transferred?
  • Brad Schoening
    Engineering | Coraid
    Tel: +1 917 304 7190
    brads@coraid.com | www.coraid.com
    Coraid: Redefinin= g Storage


From: Brian Hedstrom <B.Hedstrom@CableLabs.com>
Date: Tue, 18 Jun 2013 19:55:15 = 3;0000
To: "eman@ietf.org" <eman@i= etf.org>
Subject: [eman] EMAN Applicability = Statement Draft -02 review comments from SCTE meeting

A few months back I presented the EMAN Applicability Use Cases at the SCTE = SEMI meeting and received some feedback during the presentation.
The items I would like to feed back to this team include:
  1. What energy storage devices are IETF considering?  Does IETF cover gen= erators?
  2. We would like to request IETF to create IETF "use case patterns" = as a matrix
  3. Should IANA be listed= in "Other" under Relationship of EMAN to other Standards?=
  4. Should NEMA (instead of ANSI C12= .20) be list= ed in "Other" and "Measurement" under Relationship of E= MAN to other Standards?
  5. Sh= ould IETF draft identify SCTE & APSIS?
Thanks,

Brian Hedstrom
Senior Architect, Business & Operational Support Systems
CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
Google+: brian.hedstrom
Skype IM: brian.hedstrom 
b.hedstrom@cablelabs.com=

eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman --_000_CDE87F00B5E86bradscoraidcom_-- From B.Hedstrom@CableLabs.com Mon Jun 24 12:16:04 2013 Return-Path: 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 5887821E8170 for ; Mon, 24 Jun 2013 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 hcVUJjYwuwSt for ; Mon, 24 Jun 2013 12:16:00 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BF9B421E816F for ; Mon, 24 Jun 2013 12:15:55 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r5OJFoDF018334; Mon, 24 Jun 2013 13:15:51 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 24 Jun 2013 13:15:50 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0123.003; Mon, 24 Jun 2013 13:15:49 -0600 From: Brian Hedstrom To: Brad Schoening , "eman@ietf.org" Thread-Topic: [eman] EMAN Applicability Statement Draft -02 review comments from SCTE meeting Thread-Index: AQHObF3AGdjpkcJD2Em+66R7aDPA5pk+sfGAgAaTyYA= Date: Mon, 24 Jun 2013 19:15:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.253.129.103] Content-Type: multipart/alternative; boundary="_000_CDEDCF9F24B11bhedstromcablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [eman] EMAN Applicability Statement Draft -02 review comments from SCTE meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:16:04 -0000 --_000_CDEDCF9F24B11bhedstromcablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will work with the SCTE team on this and bring a contribution back. Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com From: Brad Schoening > Date: Thursday, June 20, 2013 7:49 AM To: Brian Hedstrom >, "eman@ietf.org" > Subject: Re: [eman] EMAN Applicability Statement Draft -02 review comments = from SCTE meeting Brian, Thanks for your feedback. I have a few questions that to help clarify * We would like to request IETF to create IETF "use case patterns" as a= matrix * I'm not sure how this would work. Could you provide a little more = description of what this matrix would look like. Would it replace the use = case patterns or augment it? * Should NEMA (instead of ANSI C12.20) be listed in "Other" and "Measur= ement" under Relationship of EMAN to other Standards? * Lately I've seen 'ANSI C12.20' referred to as 'NEMA ANSI C12.20'. = Has ownership of the C12.20 standard shared or transferred? * Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Brian Hedstrom > Date: Tue, 18 Jun 2013 19:55:15 +0000 To: "eman@ietf.org" > Subject: [eman] EMAN Applicability Statement Draft -02 review comments from= SCTE meeting A few months back I presented the EMAN Applicability Use Cases at the SCTE = SEMI meeting and received some feedback during the presentation. The items I would like to feed back to this team include: 1. What energy storage devices are IETF considering? Does IETF cover ge= nerators? 2. We would like to request IETF to create IETF "use case patterns" as a= matrix 3. Should IANA be listed in "Other" under Relationship of EMAN to other = Standards? 4. Should NEMA (instead of ANSI C12.20) be listed in "Other" and "Measur= ement" under Relationship of EMAN to other Standards? 5. Should IETF draft identify SCTE & APSIS? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CDEDCF9F24B11bhedstromcablelabscom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I will work with the SCTE team on this and bring a contribution back.<= /div>

Thanks,

Brian Hedstrom
Senior Architect, Business & Operational Support Systems
CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
Google+: brian.hedstrom
Skype IM: brian.hedstrom 
b.hedstrom@cablelabs.com=

From: Brad Schoening <brads@coraid.com>
Date: Thursday, June 20, 2013 7:49 = AM
To: Brian Hedstrom <b.hedstrom@cablelabs.com>, "eman@ietf.org" <eman@ietf.org>
Subject: Re: [eman] EMAN Applicabil= ity Statement Draft -02 review comments from SCTE meeting

Brian,

Thanks for your feedback.  I have a few questions that to help cl= arify
  • We would like to request IETF to create IETF "use case patterns" = as a matrix
    • I'm not sure how this would work. Could you provide a little more descripti= on of what this matrix would look like.  Would it replace the use case= patterns or augment it?
  • Should NEMA (instead of ANSI C12= .20) be list= ed in "Other" and "Measurement" under Relationship of E= MAN to other Standards?
    • Lately I've seen 'ANSI C12.20' referred to as 'NEMA ANSI C12.20'. &n= bsp;Has ownership of the C12.20 standard shared or transferred?

From: Brian Hedstrom <B.Hedstrom@CableLabs.com>
Date: Tue, 18 Jun 2013 19:55:15 = 3;0000
To: "eman@ietf.org" <eman@i= etf.org>
Subject: [eman] EMAN Applicability = Statement Draft -02 review comments from SCTE meeting

A few months back I presented the EMAN Applicability Use Cases at the SCTE = SEMI meeting and received some feedback during the presentation.
The items I would like to feed back to this team include:
  1. What energy storage devices are IETF considering?  Does IETF cover gen= erators?
  2. We would like to request IETF to create IETF "use case patterns" = as a matrix
  3. Should IANA be listed= in "Other" under Relationship of EMAN to other Standards?=
  4. Should NEMA (instead of ANSI C12= .20) be list= ed in "Other" and "Measurement" under Relationship of E= MAN to other Standards?
  5. Sh= ould IETF draft identify SCTE & APSIS?
Thanks,

Brian Hedstrom
Senior Architect, Business & Operational Support Systems
CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
Google+: brian.hedstrom
Skype IM: brian.hedstrom 
b.hedstrom@cablelabs.com=

eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman

--_000_CDEDCF9F24B11bhedstromcablelabscom_--