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

[Rolf Winter <[e-mail]>]

Wow, what an excellent reply :) I have nothing to add to that. Thanks Juergen!

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Juergen Quittek
> Sent: Montag, 8. November 2010 20:10
> 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)" <[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