Re: [eman] WG Last Call for EMAN Framework -09

[Benoit Claise <[e-mail]>]

Hi Juergen,

Thanks for your feedback.
Let me address the specific comments. I'll come back to the general 
comments in a different email.
Actually, I removed the vast majority of comments, with which I agree.
>       
>
> Specific comments:
>   
>
>
> 19. Section 4.1 "Conceptual Model"
> I am missing here a lot of information on the model.
> 19.1. Is the model normative or informational?
> 19.2. Is it a model to be implemented inside the EnMS only or as well on the Energy Objects?
> 19.3. If it is implemented at the Energy Objects, why storing context information? This typically resides in the management system only.
> 19.4. If it is implemented on Energy Objects, how does it specify which information is included for a device, and which (more limited) information is included for a component or power interface?
> 19.5. The model is lacking information on batteries.
Fine with the batteries.
As an battery-mib draft author, would you mind providing some text.
> 29. Section 4.2.1, 3rd paragraph:
> OLD
>          A Device Class instance may represent a physical device
>          that contains other components.
> NEW
>          A Device Class instance may represent a physical device
>          that contains other components.
?
>
> 35. Section 4.4.4, last sentence: "Demand measurements can be provided when the Energy Object is capable of measuring actual power."
> This is wrong. Either delete this sentence (preferred) or use this one instead: "Demand measurements can only be provided when the Energy Object is capable of measuring demand."
Can't we compute the demand by measuring the actual power on low intervals.
> 38. section 4.5.1 "Power State Sets"
> Why is the ACPI power state set excluded from the list of existing sets?
> ACPI power states should have their own subsection as IEEE1621 and DMTF have.
Can't check right now, but I don't think the ACPI were ever a Power 
State Set in the set of EMAN documents.
>   
> 39. Section 4.5.4. "Power State Set: IETF EMAN"
> Shouldn't we call this rather "Power State Set: Cisco EnergyWise"?
It's like Cisco NetFlow and IPFIX.
When provided the spec for IPFIX, there was no point to remind people 
that it was Cisco NetFlow.
>
> 40. Section 4.5.4, first sentence:
> "An EMAN Power State Set represents an attempt at a standard approach for modeling the different levels of power of a device." The same holds for every other power state set, particularly for the ones mentioned in the subsections above. I suggest removing this sentence.
I could either way, but the idea was to say: the other Power State Set 
were defined somewhere else.
This one is a specific attempt at the IETF.
>
> 41. Section 4.5.4.
> I am fine with the non-operational power states that also other ACPI and DMTF support similarly, but I have problems with the operational states (7-12). They are defined only relatively to each other stating that one with a lower number "provides less usage" than a higher number.
I understand that there are challenges in defining them, but I think 
there is some value in trying to standardize them.
> 41.1: Is "providing usage" proper terminology?
> 41.2: What is meant with "provide less usage"? Does it mean that usage numbers are ALWAYS lower than in a higher state? Even if measured in short time intervals? Such a behavior would hardly be implementable on many devices.
> 41.3: In the real world, power states have ranges of power values that they cover and some have wider ranges than others. This can hardly be modeled by a power state set that only knows a strict consecutive order of power states and power values.

>
>
> 43. Section 5 "Energy Management Information Model"
> The text states that this model is a "reference for implementers". Obviously, the model is useful for management system implementers. What is not discussed is how to use it for implementations of EMAN on devices, components and interfaces. The model does not give guidance for these. Among the missing information for these cases is what needs to be implemented on different classes of devices.
Replying on the last point only, I believe it's the goal of the 
applicability statement draft.

Regards, Benoit
>
> Cheers,
>      Juergen
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Nevil Brownlee
>> Sent: Dienstag, 10. September 2013 23:28
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [eman] WG Last Call for EMAN Framework -09
>>
>>
>> Hi all:
>>
>> A new revision of the EMAN Framework draft was published yesterday.
>> Version -09 has many changes, improvements and clarifications since the -08
>> version (published just before IETF-87 in Berlin).
>>
>> The WG Last Call for it starts now, and will end on Friday, 27 September.
>>
>> Please read it now, and send your comments/suggestions/etc to the EMAN list.
>> Comments like "seems fine now" are good, as are suggestions for further
>> improvement (accompanied by OLD/NEW text).
>>
>> Cheers, Nevil
>>
>> --
>> ---------------------------------------------------------------------
>>    Nevil Brownlee                          Computer Science Department
>>    Phone: [phone] x88941             The University of Auckland
>>    FAX: [phone]   Private Bag 92019, Auckland 1142, New Zealand
>> _______________________________________________
>> eman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/eman
> .
>