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

[Juergen Quittek <[e-mail]>]

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)" <[e-mail]> 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
> [e-mail] <mailto:[e-mail]>
> Phone: [phone]
> Mobile: [phone]
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eman