Re: [eman] Review of draft-norwin-energy-consider-01

Juergen,

It seems like we're in basic agreement here, that drafts and comments
should take into account existing standards.  Then, we can have an
honest debate about which standards are most relevant to our work.  

-----Original Message-----
From: Juergen Quittek [mailto:Quittek@neclab.eu] 
Sent: Monday, November 08, 2010 2:10 PM
To: Brad Schoening -X (braschoe - Piepeople Consulting,Inc. at Cisco);
eman mailing list
Subject: Re: [eman] Review of draft-norwin-energy-consider-01

Wow, what a review ...

Dear Brad,

Below please find some replies on your comments inline.
Please cool down before you reply again and read carefully what you
write.

Thanks,

    Juergen

On 09.11.10 00:30  "Brad Schoening -X (braschoe - Piepeople Consulting,
Inc.
at Cisco)" <braschoe@cisco.com> wrote:

> This document is inconsistent with the EMAN charter and should be
tabled
> or withdrawn. 

As a general comment since you do not seem to be familiar with the IETF:
Internet drafts are preferred means to contribute discussion items and
opinions to the IETF. Asking someone to withdraw a draft is comparable
to
asking someone to withdraw her or his opinion. This is not what we do in
the
IETF, at least as long as it is a technical opinion. Anyway, I would not
know means for removing a draft from the Internet draft repository.

More specifically: I am not sure what you mean with "inconsistent with
the
EMAN charter". It is indeed not one of the documents that we envision to
produce in the eman WG. But so far nobody claimed that this draft would
match any of the envisioned drafts. In contrary, Bruce stated in his
message
on this draft that this document should "reflect conclusions", "clarify
issues" and "drive decisions". No one is talking about making it an RFC.
Please find and read Bruce's announcement in the eman mailing list
archive
at http://www.ietf.org/mail-archive/web/eman/current/msg00071.html

>               It is deeply flawed in several areas.

I don't see that it even slightly flawed. Please see my replies below to
all
issues that you consider to be a flaw.

>                                                     First, it ignores
> the basic concepts of SNMP MIB management.

You are right in the sense that it ignores SNMP by not mentioning it.
But
that is all ignorance I can find. Nothing in this document is in
conflict
with any concept of SNMP.

>                                            Secondly, without
> explaining why, it ought right opposes the power models presented in
> several widely used standards such as ACPI,  DMTF's Power State and
IEC
> 61850. 

There is no statement opposing any other standard. None of the draft we
have
received for eman uses exactly ACPI or DMTF (see my next comment below).
They don't even argue why they don't do so. Are they all deeply flawed?

> These three standards for power management are well established and
> supported on millions of devices.
> 
> *         The ACPI standard for CPU power management was released in
> 1996 and  is ubiquitous today.  It defines seven power levels.

So far, none of the existing draft suggested using exactly the ACPI
model
for power states. draft-claise-power-management-arch-02 is close to
ACPI,
but it compresses the three stage model of ACPI (G,S,P) into a single
stage
model of 12 power states. No other document that I have seen for eman
suggests ignoring ACPI or does not provides means for supporting it.
Still,
the existing drafts differ in how far they limit themselves to ACPI that
was
defined specifically for PCs.

> *         IEC 61850 is supported by utilities worldwide and power
> equipment  manufacturers.   IEC 61850 has an extensive Common
> Information Model (CIM) that is the basis for many smart grid
standards.

This is correct. Where do you see the draft you have reviewed opposing
IEC 61850?

> *          The DMTF Power State Management Profile was adopted in 2008
> and defines an information model over web services.  It defines six
> power levels and aligns them with the ACPI power levels.

The DMTF has only 6 power states, 5 of them non-operational. They merged
all
operational power states into a single one: "on". This way it deviates
from
ACPI providing means for several more states. It looks like Bruce's and
Rolf's draft is going into the same direction.

BTW, so far none of the drafts contributing to eman has suggested to
adopt
the DMTF model of six power states although the DMTF focusing on network
management is much closer to the IETF network management issues than
ACPI
focusing on PC motherboards.

> Below are some detailed comments, but my view is that this document
does
> nothing to advance the charter of the working group and will be a
> distraction.  Instead we should focus on furthering the  existing
drafts
> 
> http://tools.ietf.org/html/draft-quittek-power-mib-02
> 
> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
> 
>
http://ietfreport.isoc.org/all-ids/draft-claise-energy-monitoring-mib-06
> .txt

These are all MIB modules. Right, they are on the eman charter. But as
well
on the charter are drafts on requirements, framework, and applicability.
I think the draft you reviewed is much more related to these three
drafts
than to the one you refer to.

> --------------------------------------------------
> 
> 3. "Scope of Devices" section seems to misunderstand the nature of
SNMP.
> Only devices with a network connection AND a SNMP agent can implement
> these MIBs.

I do not see any relation between this section and SNMP at all. It
definitely does not mention MIBs or SNMP. Consequently, I cannot detect
any
misunderstanding of SNMP. Are you really referring to this section or do
you
have another one in mind?

> 4.1. The 'Terminology' section on power states don't align with
existing
> standards for networked equipment (DMTF and ACPI).  The authors need
to
> clarify why they believe these pre-existing standards are in error or
> not applicable.

The drafts argues for introducing "power state categories" on, off, and
sleep. I see not problem with mapping power states defined by DMTF, ACPI
or
other bodies to these categories. Do you?

But yes, I agree that if we adopt this proposal we should elaborate on
the
mapping between these categories and the power states defined by other
bodies.

> 5.1. Control "Device Considerations" also doesn't seem to understand
how
> SNMP management works " We should not forbid power state management of
> devices that is done externally/centrally.  Today, centralized
> management is the norm with SNMP.

There is no statement forbidding anything in this short section.
Particularly, I see no indication of anyone misunderstanding SNMP. After
working with SNMP for more than 10 years now and after editing a few
standard MIB modules I still cannot see your point. Can you help me
seeing
it?

> Also, the authors need to explain how this idea relates to the current
> marketplace of existing devices that in general are externally
> controlled and only occasionally have distributed intelligence.

Good point. But you are probably aware that, for example, for mobile
access
networks so-called "Self-Organizing Networks" (SON) for self-management
of
base stations is already included in 3GPP standards. And energy
management
functions is the next application area for SON.

> 5.2 The comment about URL's seems ignorant of SysObjectID and not
> relevant to the EMAN charter

Maybe. But so far, I do not consider the identification of energy
consumers
being solved by the eman WG. Proposals are still welcome. Whether the
eman
WG or another WG will solve this problem is to be discussed.

> 5.3 For "NMS Considerations", the authors need to clarify how this
> relates to existing energy management systems and existing standards
> such as IEC 61850 that define interval measurements.

Good point. IEC 61850 is important and should not be ignored.

> 5.7 "For the device power state, the following information is
considered
> to be relevant"...   This doesn't reference any existing standards and
> is therefore largely irrelevant.

A very strange argument. Issues not covered already by existing
standards
should not be dealt with by the IETF?

> 5.8 "Devices can report power for another device only if they are the
> 
> entity providing the power"  This would rule out managing PC's which
> typically don't have a SNMP agent.   We probably don't want to forbid
> this.

No, it rules out PCs that do not report their own power consumption. If
no
device is connected to the PCs power line then the PC has to report
power on
its own, because no other device will know its current power. This is
quite
obvious. But I agree with you, that the authors should think about
including
relaying of information from such PCs into their considerations.

> 6.o "Use Case: A house... A vehicle"  This further ignores basics
about
> SNMP.  Existing use cases for SNMP are not homes or vehicles.

You talk about "basics". Do you claim that a "basic" property of SNMP is
that it cannot be applied in homes?

Let's try to be more constructive next time.

    Juergen

> Brad Schoening
> Consultant
> Product Development
> braschoe@cisco.com <mailto:braschoe@cisco.com>
> Phone: +1 408 424 0363
> Mobile: +1 917 304 7190
> 
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>
> 
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman