Subject: [eman] Draft proposal for consideration at upcoming meeting

From: "Chris Verges" <[email-masked]>
Date: Wed, 23 Feb 2011 21:11:45 -0800

Dear all,

The eman mailing list has been silent for several weeks now, and I began
to wonder whether the existing proposals were continuing to be developed
and changed based on the objections and feedback noted on the mailing
list and from the Beijing meeting last year.  As an implementer, the
current drafts raise some serious concerns about both usability and
maintainability going forward.  (These concerns are documented in the
attached document.)

Attached is a new draft for the agenda at the upcoming Prague meeting.
This new document aims to combine the best aspects of the existing
proposals into a single document and to create a new schema that should
be more workable for a wider variety of entities (servers, switches,
PDUs, etc.)  It was easier to write a new draft than to try and change
the original ones.

I will be unable to attend Prague in person due to other work
commitments, but will attend virtually via the Jabber session.  If
someone familiar with the working group's proceedings could please let
me know what is needed to proceed under these conditions, I would be
most appreciative.

Thanks,
Chris

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 Feb 2011 12:05:27 +0100

Hi Chris,

The WG chairs will certainly provide you more detailed advice - but to
start, first you need to submit the Internet-Draft (before 3/7 which is
Internet Draft Cut-off for initial documents (-00)) and ask them to put
you on the agenda of the WG meeting. It would be good to find somebody
who attends the meeting to present on your behalf, and you can follow
the audio-stream and respond on jabber to questions from the room. 

I hope this helps,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Chris Verges
> Sent: Thursday, February 24, 2011 7:12 AM
> To: [email-masked]
> Subject: [eman] Draft proposal for consideration at upcoming meeting
> 
> Dear all,
> 
> The eman mailing list has been silent for several weeks now, 
> and I began to wonder whether the existing proposals were 
> continuing to be developed and changed based on the 
> objections and feedback noted on the mailing list and from 
> the Beijing meeting last year.  As an implementer, the 
> current drafts raise some serious concerns about both 
> usability and maintainability going forward.  (These concerns 
> are documented in the attached document.)
> 
> This new document aims to combine the best aspects of the 
> existing proposals into a single document and to create a new 
> schema that should be more workable for a wider variety of 
> entities (servers, switches, PDUs, etc.)  It was easier to 
> write a new draft than to try and change the original ones.
> 
> commitments, but will attend virtually via the Jabber 
> session.  If someone familiar with the working group's 
> proceedings could please let me know what is needed to 
> proceed under these conditions, I would be most appreciative.
> 
> Thanks,
> Chris
>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 Feb 2011 17:08:56 +0100

Hi Chris,

> list and from the Beijing meeting last year.
To be frank, the mailing list being so silent, is also a concern to me.
I know that some work is being done in the background, but this lacks 
visibility. Hence you're valid concern...
> As an implementer, the
Thanks for your work on this one. Much appreciated.

Here is a proposal.
- Can we please get some feedback on the EMAN requirement drafts, on the 
mailing list.
   We want to make sure that we solve the right problem.
   As you categorized yourself as an implementer, your feedback is 
extremely important.
   You know, even a message such as: "I read it and it makes sense!" 
would be useful.
- From there, if we agree, we should be looking at the framework, 
because the different MIB modules are based on the content of the framework.
   And for the framework, if we could start with the terminology. I've 
seen two emails on this terminology. Any other views?
> me know what is needed to proceed under these conditions, I would be
If nobody else proposes himself, one of the two chairs will do it.

Regards, Benoit.
> Thanks,
> Chris
>
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 25 Feb 2011 04:36:54 -0600

Hi Chris,

Thanks for your email which has infused energy in the email list. 

I read your draft and I have some comments and questions. 

Based on the EMAN Charter, there was a requirement that there shall 2
areas of work. 
    3. Energy-aware Networks and Devices MIB document 
    4. Power and Energy Monitoring MIB document 

Our drafts
http://www.ietf.org/id/draft-ietf-eman-energy-aware-mib-00.txt,
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
are work items based on the WG charter goals. 

In summary, your proposed MIB module has concepts from our MIB proposal
(pmPowerCategory, pmPowerAccuracy, pmPowerNameplate, pmPowerType, ...). 
Our new MIB draft that we are working on shall be posted in a few days
has a new proposal for PowerStates - 

There are some new additions in terms of EmanDataAlertEntry and
EmanContextEntry and a simplified proposal for PowerStates and a new
grouping of LLDP Indices in  EmanLldpEntry. 

EmanDataAlertEntry  -  Alerts from a power monitoring sense are quite
useful at an aggregate level, when there electrical overload, which may
cause potential circuit breaks. Since the index is emanEntityIndex is it
useful to have alerts for power at an entity level ?  Routers have
alerts when the heat dissipation exceeds a threshold and the router is
shutdown. 

According to the requirements draft,
https://wiki.tools.ietf.org/html/draft-ietf-eman-requirements-00  it was
required to keep track of additional statistics - total time spent in
each state, power consumption in each state, ....In addition to power
consumption, Energy measurement is also another requirement. 

We are working on a revised MIB draft that shall be posted soon, and
that contains a proposal for a modified PowerState modeling of entities.

The detailed MIB structure of the PowerQuality MIB module is based on
the IEC 61850 standard. 

Regarding the NamePlate Power consumption we have provided only the
Maximum value in Watts. As you have pointed it may be useful provide the
Volts and Amperes etc.  The reason for the choice of pmPowerNamePlate
was, in the absence of actual measurement, atleast we atleast have the
worst case power consumption of the device that can be useful for
planning purposes. However, not sure of the minimum value of NamePlate
from a network management point of view. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Verges
Sent: Thursday, February 24, 2011 10:42 AM
To: [email-masked]
Subject: [eman] Draft proposal for consideration at upcoming meeting

Dear all,

Thanks,
Chris

---

From: "Chris Verges" <[email-masked]>
Date: Fri, 25 Feb 2011 07:27:15 -0800

Hi Mouli,

Thanks for the feedback.  I'm not entirely sure what was a comment and
what was a question, so I'll address what I can.  Please let me know if
I missed something.

My draft combines charter items #3 and #4 into the same draft document,
with #3 being handled by the EMAN-CORE-MIB components and #4 by
EMAN-DATA-MIB.  Yes, it does share concepts with both the Cisco MIBs
(Claise/Parello) and Quittek's MIB, as I mentioned in Section 3.  I
don't balk at the concepts that those MIB proposals have introduced,
just the organization.  If the existing proposals will change, I would
love to see what those changes will be.  The document that I recently
published tries to encompass what such a structure should look like to
ensure that it works with PDUs and generic energy devices.  Obviously,
my goal is to have a MIB set that works with intelligent PDUs from
vendors like Cyber Switching, Raritan, etc. and the current MIBs lack
sufficient structure and/or are extremely complex for end users who have
to consume the data.

All PDUs will send alerts (high current thresholds, low current
thresholds, Virtual Circuit Breaker, etc.) for the unit as a whole,
individual banks, and individual outlets.  So for complex devices like
an intelligent PDU, having alerts defined for each component is
essential.  But more critically, we should not be thinking of a MIB
schema in terms of what we need for today's devices, but rather in terms
of what we need for tomorrow's.  A router today might currently only
send 1 alert, but if we define the MIB design in terms of this, you lose
the ability to change your router's feature set to break that down
further later.

The core focus and purpose of this draft is not to nail down every
detail described in the requirements document.  The point is to setup a
core framework that can then be extended through role-specific add-ons
for historical state transitions, kWh measurements over time, etc.  In
short, you can add on an emanControlDeltaUsageTable sparse table to
capture the "delta" between any two states and the current state.  But
it isn't tied specifically to data reporting, control, or the core
definition of an entity.  The existing proposals are so highly coupled
that there exists no flexibility for change in the future without
potentially breaking backwards compatibility.

Nameplate ratings are often written in terms of a range:  120V/240V
4A/2A.  Such a description mapped to the nameplate schema in my draft
would be: 

    Maximum voltage = 240V
    Maximum amperage = 2A

    Minimum voltage = 120V
    Minimum amperage = 4A

The two go together as a set.  You are correct in that the "max/min"
nomenclature IS confusing, though I don't know of a better way off the
top of my head.  Any suggestions for what wording might be better to use
here?  I did consider having "NameplateRating" simply be an
SnmpAdminString and just capture things as a string rather than trying
to break it down as numbers.

To address a common question that I'm hearing, all PDU vendors provide
their MIBs for public consumption.  Here's a short list:

http://www.cyberswitching.com/zip/CYBERSWITCHING-MIBS-v4.2.0.zip

http://www.raritan.com/support/dominion-px/1.3.5/MIB/PX131MIB.zip

ftp://ftp.servertech.com/pub/SNMP/sentry3/

http://www.apc.com/tools/download/index.cfm (firmware upgrades - mib /
register for login)

Thanks,

Chris

-----Original Message-----
From: Mouli Chandramouli (moulchan) [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 2:37 AM
To: Chris Verges; [email-masked]
Subject: RE: [eman] Draft proposal for consideration at upcoming meeting

Hi Chris,

Our drafts

Thanks
Mouli

-----Original Message-----

Dear all,

Thanks,
Chris

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 25 Feb 2011 10:17:41 -0600

Hi Chris,

Comments in line.  

Thanks
Mouli

-----Original Message-----
From: Chris Verges [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 8:57 PM
To: Mouli Chandramouli (moulchan); [email-masked]
Subject: RE: [eman] Draft proposal for consideration at upcoming meeting

Hi Mouli,

EMAN-DATA-MIB.  

YCM> Until the Anaheim IETF meeting, we did have an integrated MIB
module. 
YCM> Based on the EMAN WG Charter, it was decided to make those two MIB
modules. 
YCM> The MIB modules are also designed in such a way monitoring MIB can
be used 
YCM> independent of the energy-aware MIB. 

Yes, it does share concepts with both the Cisco MIBs

YCM> It would be useful to be specific instead of a generic comment -
lack of structure.
YCM> There is a lot of detail and those need to be covered. If there are
redundant data
YCM> it is possible reexamine/reorganize those MIB variables. 

essential.  

YCM> Yes, I agree. High and low alerts may be useful at a PDU level. 
YCM> But a box level and the sub-components of a box, it may not be
useful to have alerts. 

But more critically, we should not be thinking of a MIB

YCM> As you have pointed, it may be possible to have such high and low
threshold alerts for network devices,
YCM> Right now, one of the goals is to have the basic functionality of
standardized power monitoring in network devices. 

The core focus and purpose of this draft is not to nail down every
detail described in the requirements document.  The point is to setup a
core framework that can then be extended through role-specific add-ons
for historical state transitions, kWh measurements over time, etc.  

YCM> The question is which comes first - requirements - to nail down
which problem we are trying to solve. 
YCM> Then once we agree on the problem scope, the appropriate solution
can be provided. 
YCM> It may be more useful to add those specific areas of monitoring to
the requirements.

In short, you can add on an emanControlDeltaUsageTable sparse table to

    Maximum voltage = 240V
    Maximum amperage = 2A

    Minimum voltage = 120V
    Minimum amperage = 4A

YCM> Thanks for the PDU references. 

Thanks,

Chris

-----Original Message-----
From: Mouli Chandramouli (moulchan) [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 2:37 AM
To: Chris Verges; [email-masked]
Subject: RE: [eman] Draft proposal for consideration at upcoming meeting

Hi Chris,

Our drafts

Thanks
Mouli

-----Original Message-----

Dear all,

Thanks,
Chris

---

From: [email-masked]
Date: Sat, 26 Feb 2011 22:48:03 -0800

Hi Mouli,

Comments inline, some parts clipped for readability.

On Fri, Feb 25, 2011 at 10:17:41AM -0600, Mouli Chandramouli (moulchan) wrote:
> YCM> module. Based on the EMAN WG Charter, it was decided to make
> YCM> those two MIB modules.  The MIB modules are also designed in
> YCM> such a way monitoring MIB can be used independent of the
> YCM> energy-aware MIB.

I'm not quite sure how to respond to this.  I interpret this to say that
the core group of people who wrote the EMAN WG Charter were the same
people who wrote the energy-aware MIB and the power-monitoring MIB, and
that they ensured consistency in these three documents.  Is that a fair
statement?

I am very confused at your statement regarding the independence of the
two MIBs (energy-aware and energy-monitoring.)  The pmIndex OID was
defined in energy-aware and referenced in energy-monitoring, so I'm not
quite sure how these are independent; it seems more than
energy-monitoring is highly dependent on energy-aware.  Please feel free
to shed light on my misunderstanding.

> YCM> lack of structure.

Plainly and specifically, ENERGY-AWARE-MIB seems to be a direct dump of
Cisco EnergyWise.  The pmTable structure closely links the definition of
an power entity object with certain decorator properties that aren't
critical to the core notion of the entity.  Some examples are
pmDomainName, pmLldpPortNumber, etc.  I felt that I was very specific in
Section 3 ("Relationship to Other EMAN Proposals") in the draft that I
uploaded.  Was there a particular point to that section that you would
like to rebut?

> YCM> redundant data it is possible reexamine/reorganize those MIB variables.

The issue is not one of redundancy, but one of necessity -- or more
properly, one of "un-necessity."  As I read the energy-aware and
power-monitoring drafts, a single question keeps coming up in my mind:
"Is this aspect of the proposal really necessary?"

First and foremost, I think that a "core" list of entities is required.
I think that all three draft proposals share this concept based on
certain similarities.  In my draft proposal, it's covered by
emanEntityTable.  This table includes only the properties that are
absolutely essential for defining what the entity is.  I am proposing
the core set of attributes:

   emanEntityIndex
   emanEntityName
   emanEntityAlias
   emanEntityType
   emanEntityCapabilities
   emanEntityParent
   emanEntityPhysicalId
   emanEntityLogicalId

Any entity, whether a switchport or a server or a PDU outlet, requires
these attributes be defined in order to identify the entity uniquely.

All other attributes are "decoration."  Instantaneous "power" data,
control mechanisms, historical "energy" data, domain/keywords/importance
(i.e.  "context" information) -- these are all highly specific to
particular entities.  Some entities may offer control mechanisms
(ACPI/DMTF power transitions, for example).  Others may offer
power/energy data (intelligent PDUs, for example.)  Some may do both at
the same time.  My proposal is that these properties be split off into
separate sparse tables (at a minimum) or even separate MIB modules that
can be defined in piece-meal fashion as the EMAN WG develops a better
understanding of the use cases surrounding the individual components.

The current proposals are monolithic in their approach, by tightly
coupling identifing details with optional decoration.  The draft that I
uploaded attempts to break this coupling, make it looser, and therefore
more flexible for change in the future.  At least, that is the goal, and
I would welcome insight into how to make it more flexible.

> YCM> useful to have alerts.

My proposal allows for the flexibility to selectively choose what
features to enable/disable at the level desired.  If you only want
alerts on the router level, fine.  If you need alerts at the outlet
level, you can do that, too.

More critically, however, your comment has gotten me to wonder whether
you are intending to support PDUs in the EMAN standards.  Since a PDU's
entire function is to help perform "Energy Management," I assumed that
PDUs along with servers and switches would be the core targets for the
EMAN standards, and so the standards would need to be written in a way
that offer the flexibility to address ALL categories.  Please let me
know if you feel the scope of the EMAN group is different than my
understanding, as this would be a core point to address before anything
else.

> YCM> threshold alerts for network devices,  Right now, one of the goals
> YCM> is to have the basic functionality of standardized power monitoring
> YCM> in network devices.
>
> YCM> which problem we are trying to solve.
> YCM> can be provided.
> YCM> the requirements.

I agree that nailing down requirements first is required.  I would even
go so far as to say that requirements will change over time, and that we
will miss some "latent" requirements just due to the natural way of
things in projects as complex as this.  So I urgently believe that the
core definition of what it means to be an entity needs to be so detached
from all of the "decorations" surrounding it, so that we can address
specific points as our understanding further develops.

> ...(lines snipped)...

Please take a look, as these four companies have been addressing energy
management of complex systems for over 50+ years (combined experience.)

I think of a PDU as a hierarchical dissection of the following objects,
based on the way that power flows through the internal construction:

   PDU
   |-- Network/Overhead Logic
   |-- Input X
   |   |-- Bank Y
   |   |   |-- Outlet Z
   |   |   `-- ...
   |   `-- ...
   `-- ...

Each node in this hierarchy can have power/energy data, state/control
ability, etc.  They are all related to each other, too, in the power
flow.

A server can be broken down similarly:

   Server
   |-- Network/Overhead Logic
   |-- Power Supply X
   `-- ...

A PoE-based switch follows a similar pattern:

   Switch
   |-- Network/Overhead Logic
   |-- Ethernet Port X
   `-- ...

(Each "..." line reflects a repetition of the line/subtree immediately
above it.)

Given this commonality in structure and objective, it makes sense to
address all of these entities in a way that allows us to manage power
independently of what type of entity it is.  Power is the central
concept here, not PDUs or switches or servers.  Reflect power, and you
will create a model that is universally useful.

Thanks,
Chris

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Sun, 27 Feb 2011 11:53:17 -0600

Hi Chris, 

Comments inline. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 27, 2011 12:18 PM
To: Mouli Chandramouli (moulchan)
Cc: [email-masked]
Subject: Re: [eman] Draft proposal for consideration at upcoming meeting

Hi Mouli,

On Fri, Feb 25, 2011 at 10:17:41AM -0600, Mouli Chandramouli (moulchan)

YCM>>> No, it is not an accurate statement. As I had mentioned before,
it is actually the other way around. 
YCM>>> Based on the WG Charter, the MIB documents had to be reorganized.
The WG charter was formulated and circulated to all for comments. 

YCM>>> Please stay tuned for the MIB document to be published. 

YCM>>> I read your draft which says that pmLldpPortNumber may not be
needed for PDUs.

YCM>>>I read your draft which says that pmLldpPortNumber may not be
needed for PDUs. Fair point. 
YCM>>> Beyond that you seem to be questioning the why the 2 drafts are
split. Please read comment on WG Charter. 

   emanEntityIndex
   emanEntityName
   emanEntityAlias
   emanEntityType
   emanEntityCapabilities
   emanEntityParent
   emanEntityPhysicalId
   emanEntityLogicalId

YCM>>>   emanEntityIndex - pmIndex 
YCM>>>   emanEntityName  - pmName 
YCM>>>  Most of these attributes you have proposed are already present
in the energy-aware MIB except for Entity Capabilities and LogicalId.

YCM>>> I do not follow this terminology - monolithic, decoration ....

YCM>>> If a device is energy-aware that would be part of the WG charter
I think. 
YCM>>> I am a contributor with a networking hat and I want to add my 2
cents. 

YCM>>> In a sense, from your MIB, it is possible to infer some
additional requirements from the PDU point of view. 
YCM>>> We shall discuss those at the WG meeting. 

   PDU

   Server

   Switch

Thanks,
Chris

---

From: [email-masked]
Date: Sun, 27 Feb 2011 12:41:02 -0800

> YCM>>> Please stay tuned for the MIB document to be published.

While I will certainly review any updates to the existing drafts, I
invite feedback regarding the draft that I have already published as it
relates to the proposed changes that you are integrating into your draft
update.

When Parello published his drafts, he requested that we review them.  I
did, and gave criticism similar to what I've been describing here.  We
met for dinner, and I again shared my concerns.  When it looked like
nothing had been done for nearly 3 months to address them, I published a
draft to force these issues to be addressed.  My draft specifically
highlights the concerns and proposes a solution.

I'm tired of "staying tuned" for you guys to implement these changes and
propose a second rev.  When you actually do publish it, I'm happy to
review, as I've done for all of the drafts published so far.  I ask that
you give me the same courtesy and professionalism and return the favor.

How, specifically, is my draft different than what you will be
proposing?  How do you feel it needs to be changed to bring it in-line
with your ideal MIB schema?

> YCM>>> I read your draft which says that pmLldpPortNumber may not be

Is this a point with which you disagree or simply a statement?

> split. Please read comment on WG Charter.

There seems to be a miscommunication, then.  I'm not arguing why there
are two drafts.  I'm arguing that the internal MIB structuring described
in those two drafts isn't ideal.

I'll comment on the MIB structure defined in the Charter: it put the
cart before the horse.  To think that all devices could be covered by
three MIBs -- energy-aware, power-monitoring, and battery -- is
presumptuous.  Not only is this organization unflexible, but it doesn't
reflect an adequate focus on the needs of intelligent PDUs, Smart Grid
equipment, or other non-server/switch equipment.  Be open to the notion
that the Charter may need to change, or else you're solving the wrong
problem.

> in the energy-aware MIB except for Entity Capabilities and LogicalId.

My point is that the energy-aware MIB contains MORE than just this, and
it shouldn't.  The features supported by energy-aware need to be pared
down to a more core subset, as I've done in my draft proposal.

> YCM>>> I do not follow this terminology - monolithic, decoration ....

monolithic - http://en.wikipedia.org/wiki/Monolithic_system

   A software system is called "monolithic" if it has a monolithic
   architecture, in which functionally distinguishable aspects (for
   example data input and output, data processing, error handling, and
   the user interface), are not architecturally separate components but
   are all interwoven.

decorator - http://en.wikipedia.org/wiki/Decorator_pattern

   In object-oriented programming, the decorator pattern is a design
   pattern that allows new/additional behaviour to be added to an
   existing object dynamically.

   The decorator pattern can be used to make it possible to extend
   (decorate) the functionality of a certain object at runtime,
   independently of other instances of the same class, provided some
   groundwork is done at design time.

coupling - http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29

   In computer science, coupling or dependency is the degree to which
   each program module relies on each one of the other modules.

   Coupling is usually contrasted with cohesion. Low coupling often
   correlates with high cohesion, and vice versa. The software quality
   metrics of coupling and cohesion were invented by Larry Constantine,
   an original developer of Structured Design[1] who was also an early
   proponent of these concepts (see also SSADM). Low coupling is often a
   sign of a well-structured computer system and a good design, and when
   combined with high cohesion, supports the general goals of high
   readability and maintainability.

   Tightly coupled systems tend to exhibit the following developmental
   characteristics, which are often seen as disadvantages:

      1. A change in one module usually forces a ripple effect of
         changes in other modules.

      2. Assembly of modules might require more effort and/or time
         due to the increased inter-module dependency.

      3. A particular module might be harder to reuse and/or test
         because dependent modules must be included.

cohesion - http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

   In computer programming, cohesion is a measure of how
   strongly-related the functionality expressed by the source code of a
   software module is. Methods of measuring cohesion vary from
   qualitative measures classifying the source text being analyzed using
   a rubric with a hermeneutics approach to quantitative measures which
   examine textual characteristics of the source code to arrive at a
   numerical cohesion score. Cohesion is an ordinal type of measurement
   and is usually expressed as "high cohesion" or "low cohesion" when
   being discussed. Modules with high cohesion tend to be preferable
   because high cohesion is associated with several desirable traits of
   software including robustness, reliability, reusability, and
   understandability whereas low cohesion is associated with undesirable
   traits such as being difficult to maintain, difficult to test,
   difficult to reuse, and even difficult to understand.

   Cohesion is often contrasted with coupling, a different concept.
   Nonetheless high cohesion often correlates with loose coupling, and
   vice versa. The software quality metrics of coupling and cohesion
   were invented by Larry Constantine [1] based on characteristics of
   "good" programming practices that reduced maintenance and
   modification costs.

Typically, monolithic systems tend to be highly coupled, which makes for
horrible maintenance cycles.  A single change might ripple through the
entire system, causing incremental changes in seemingly disparate
subsystems.

I highly recommend "Design Patterns" by Gamma, Helm, Johnson, and
Vlissides (the Gang of Four) and "Patterns of Enterprise Application
Architecture" by Fowler.

The basic pattern that I'm following:

  +-------------+          +-----------+
  | PowerObject |          | Decorator |
  +-------------+          +-----------+
  |             |<>--------|           |
  +-------------+          +-----------+
  |             |          |           |
  +-------------+          +-----------+

Replace "Decorator" with "PowerData", "AcpiControl",
"DmtfPowerStateControl", "PercentageControl", "LldpInfo",
"EnergyWiseContext", etc.  The point is to say that such add-on feature
sets should be sparse table extensions, not integrated into the core
entity table.

> YCM>>> I think.
> YCM>>> cents.

This is a good start to being on the same page, then.  If we all agree
that the deliverables from the EMAN WG are to support energy management
for all networked devices that consume, meter, and control electricity,
then we've established a commitment to ensuring flexibility in the
design to cover not only the use cases that we think of today but also
the ones that could arise in the future.

> YCM>>> additional requirements from the PDU point of view.

Let's discuss them _before_ the WG meeting.  Given that I won't be present
at the meeting, no reason we can't dive into it electronically.

Thanks,
Chris