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

[Juergen Quittek <[e-mail]>]

Hi Brad,

Wow, again. 

I objected almost every point you made and you see us in basic agreement.
Are you now fine with the draft that you reviewed?
No problems with it anymore?

Great!

    Juergen


On 09.11.10 04:19  "Brad Schoening -X (braschoe - Piepeople Consulting,Inc.
at Cisco)" <[e-mail]> wrote:

> 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:[e-mail]]
> 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)" <[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