Subject: [eman] Introduction; past comments

From: Bruce Nordman <[email-masked]>
Date: Mon, 1 Nov 2010 23:49:07 -0700

Greetings--

  As incoming co-chair of eman, I look forward to meeting many of you
next week in Beijing.  I bring an energy-centric background to the process,
which I believe will be a useful complement to more usual IETF participants.
I have been on the edge of several IETF meetings, but this will be my first
actual attendance.  You can learn more about my interests from my web page
(below).
  For our working group, I have no interest in expanding our charter.
I am however
interested in follow-on activities that may make sense within the IETF
as well as in
other standards organizations, for how we network the physical world
(I call this
"building networks" for devices that use energy or that influence it).
 I look forward
to discussions on this outside our WG meeting.
  In the interest of transparency and completeness, below are some comments on
several of the Internet Drafts as they were a few weeks ago, before
recent revisions.
These are offered as an individual participant, not in my role as
co-chair.  I am not
seeking to start email discussions with these comments.
  Pleasant travels,

--Bruce

-- 
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

claise-power-management-arch-01
   “power level” to me is a measurement in watts of the device.  I
prefer “power mode” or “power state” (I treat them as synonyms and
don’t much care which is used) for states like on, sleep, off.
  1. Introduction – any device on an IP network should be in scope,
and while today that is almost entirely IT devices, in future it may
be dominated by non-IT ones.
  Power Monitor – I see this as something which tracks power coming
into a device, or going out of it (the meter case could be either, the
only difference being whether the meter consumption is included or
not).  (actually, section 5.1 of c-p-m-mib states this).  Every device
can measure its power input.  Power output can be measured on any
interface that provides power.  We need to be clear about which side
of a link the measurement is on, as the line losses will be included
if on the supply side, but not if on the demand side.  Could of course
have a power monitor on both.  The examples should be organized along
these lines (the distinction is already mentioned).  The text says
that a PM can be “independently managed”.  How does one manage a
device or component if it does not have an IP address?
  Power quality – I wasn’t sure if it was quality of the power or of
the measurement being referenced here.
  “each monitor must be a member of a domain”. – why?  I think each
device must be able to operate independently, and if it discovers it
has a parent, then be able to report up to it, but not have that be a
requirement.  It seems like some of the discussion references a
reporting hierarchy along the lines of the LAN structure, e.g. up to a
switch, but if the power is not distributed along the same lines, this
seems like a problem.
  4.3 – clarify if the connection referenced is for communications,
power, or both.
  Keywords – I think that consideration of these in the context of use
cases may lead us to pulling aside a few key attributes, such as
location and identity; the “role description” concept is doing this
already.
  4.5 – Again, I think the number of basic states is far more than
needed, and that differentiation within a state should be accomplished
by other means (often strictly internal to the device, with the
preference – e.g. expressed by price – being manifested in lower power
levels that are reported).
  4.6 – Is “instantaneous” finer than one AC cycle?  I don’t think it
needs to be (perhaps can’t or shouldn’t), and could be more than one.
Also, nameplate power is so far from reality I don’t think worth
bringing up.  I do think worth considering a value for maximum
possible demand for the device in question (if this is what was meant
than I would not use nameplate as it has other meaning).
  4.8 – demand charges.  I suspect these will eventually disappear as
we move to dynamic prices, so I would not let them change the
architecture.   Besides, a NMS can always query a device every 15
minutes to get its contribution to peak for the building.  Also, I
would leave off the two bullets at the end as out of scope, or at
least move the topic to the introduction.
  5. Presumably a power supplying device may sometimes not be able to
contact those it is serving power to, either because they lack
communications, or the comms are not on the same link and so may not
be present even though power is being used.
  Manufacturers power levels.  I am not convinced we need this
concept.  Again, I think the use cases will help.
  IEC 61850 – is this important?  Does someone have a PDF they can send me?

quittek-power-mib-01
   For accuracy, I suspect eventually that direct measurement will
become cheap, but agree that in the meantime many devices won’t have
this.  However, I suspect most of those can reliably estimate their
energy use from other factors, so I think that making good use of
estimates is important to facilitate (while exposing the accuracy
reduction for those devices that care).
  I didn’t print out quittek-power-monitoring-requirements so these
comments don’t reflect that document.
  Power states – the term “low power mode” is useful (and a way to
avoid using the word “standby”).
  3.1 entity state mib – worth considering if what they are getting at
here is the functional state, rather than the power state.  While they
are related, I think usefully distinguished, and perhaps key to
explaining the relationship between what we define and what this mib
already defines (even if what it defines in this case goes away).
  Also in 3.1, as noted above, I don’t think we need more detail in
power states, or rather, additional complexity should be driven by use
cases, as I think the needs they have will point us to a different
solution.
  4.1 – detail about power supply voltage, etc.  Why do we care about
this? What about devices with multiple power supplies, of the same
type, or heterogeneous?
  4.1 – is it normal to mix static values with highly dynamic ones?  I
have an urge to keep these separate, but am not familiar with mib
design.
  4.1 – I think the sentence under the table is key – that current
power and accumulated energy are the main items of interest in most
cases.  That needs to be kept front and center.
  4.1 – interruptions – I assume this is from power cycles or from
system OS failure.  As in other cases, I’d like to see use cases
inform this.  I’m not sure what solution(s) might make sense, but I am
reluctant to add too much complexity for this.  A real issue
regardless.
  5. batteries – are the alarm levels being simply reported, or being
set by an external device?

claise-energy-monitoring-mib-05
  6. – scenario 1 – “switch does not have a parent” – doesn’t this
violate the statement that every monitor is part of a domain?  Mind
you, I don’t think that should be a requirement (to have a parent).
  6. – scenario 7 – the paragraph above the diagram seems key – the
relationship between parent/child re: communications, re: power
distribution, and re: control.  I don’t think we have clarity on this
yet.

---

From: Christian Groves <[email-masked]>
Date: Wed, 03 Nov 2010 13:33:15 +1100

Hello Bruce,

Thanks for the introduction.

Your comment on other SDOs and the charter actually made me have a good 
read of the EMAN charter. It mentions a list of SDOs whose work may be 
applicable: IEC, ANSI, DTMF etc. However it doesn't mention ITU-T Study 
Group 5"electromagnetic compatibility and electromagnetic effects" 
<http://www.itu.int/net/ITU-T/lists/questions.aspx?Group=5&Period=14>. 
This group was formed from two study groups, one looking at 
electro-magnetic issues and one looking at indoor and outdoor plant. My 
understanding is that operators are well represented in this group. It 
may be beneficial for both SG5 and the EMAN WG to exchange information.

Regards, Christian