Energy Management Framework
draft-ietf-eman-framework-19
Yes
(Joel Jaeggli)
No Objection
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
Recuse
(Benoît Claise)
Note: This ballot was opened for revision 15 and is now closed.
Joel Jaeggli Former IESG member
Yes
Yes
(for -15)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-03-17 for -16)
Unknown
I have no objection to the publication of this document, but here are a number of comments about the text. I think you would be well advised to work on a new revision before publication. --- I note in the data tracker that this document does not have IETF consensus. Really? --- From the Shepherd write-up and Ballot... This document is an EMAN Working Group document, adopted in 12/22/2010, and which passed WG last call in July 2010. Impressive messing with the space-time continuum. From the write-up Response to the WG adoption call was <need Benoit's input here>. I guess Benoit is shy (or no-one asked him). From the write-up (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes. Disclosure 2161: https://datatracker.ietf.org/ipr/2161/ Does that mean no discussion and conclusion? --- Shame about the formatting and "rndom" page breaks which made it just a bit harder to review the document. --- Odd to find RFC 2119 "MUST" in use... 6.3.6 An Energy Object MUST be a member of a single Energy Management Domain therefore one attribute is provided. I think s/MUST be/is/ 12.1 The group of experts MUST check the requested state for completeness and accuracy of the description. You seem to be happy using lower case for other constraints on the expert reviewer. --- I think the notation "(Class)" is never actually explained. At least, I had got some way through the document assuming I knew what it meant before I realised I should check, and then I couldn't quickly find a definition. --- Non-electrical equipment... Section 1 The framework does not cover non-electrical equipment nor does it cover energy procurement and manufacturing. Section 2 non-electrical equipment (mechanical equipment) A general term including materials, fittings, devices, appliances, fixtures, apparatus, machines, etc., used as a part of, or in connection with, non-electrical power installations. Section 5 Non-Electrical Equipment The primary focus of this framework is the management of electrical equipment. Non-Electrical equipment can be covered by the framework by providing interfaces that comply with the framework. For example, using the same units for power and energy. Therefore, non-electrical equipment that do not convert-to or present-as equivalent to electrical equipment are not addressed. ...seems to me like you are wavering :-) --- Seciton 6.1 This section describes an information model that addressing s/addressing/addresses/ --- Section 6.1 This section proposes a similar conceptual model for Do you intend that this remains a proposal in the RFC, or will it become a definition? --- Section 6.2 I don't think that the plural of "Energy Object (Class)" is "Energy Object (Class)'s". Fortunately, the way you used it should not have a plural. Read... There are three types of Energy Object (Class): --- Section 6.2 I struggled a bit with the distinction between device and component. The most basic atom of eman is presumably a component. And the largest element of eman is a device (since you do not talk about networks being manageable in this document). But this section appears to say that a device may be made up of components. So, would I be right in saying that a device cannot be made up of devices, but that a component may be made up of components? Consider: Router Line card Laser The term "physical piece of equipment" didn't really help me. Is a physical piece of equipment something that can be picked up without disintegration? Or is it something that cannot be disassembled without recourse to a hammer? Where do router, line card, and laser fit into that? --- Section 6.3.1 Every Energy Object has an optional unique printable name. That seems to have let the internationalisation cat out of the bag. What do you mean by "printable"? And later in the same paragraph: "test string"? --- 6.3.3 Although EnMS and administrators can establish their own ranking, the following example is a broad recommendation for commercial deployments [CISCO-EW]: 90 to 100 Emergency response 80 to 90 Executive or business-critical 70 to 79 General or Average 60 to 69 Staff or support 40 to 59 Public or guest 1 to 39 Decorative or hospitality Is this provided for information or as a recommendation of this I-D? If the former: why do we care? If the latter: you may mean "RECOMMENDED" and you certainly don't need the reference. --- 6.3.4 Hasn't the discussion of key words (here and later) departed from information model and entered into data model? From the point of view of an information model, all that is needed is to say that tags exist and to say what the tags can represent. --- Section 6.5 A number of acronyms show up unexpanded (DMTF, ACPI, PWG). While some have references to help explain them, PWG is unexplained. --- Sections 6.5.4 and 6.5.5 The eman power states are shown in lower case and in title case. Is there a difference in meaning or should they be consistent? --- Section 7 s/a MIB/MIB modules/
Jari Arkko Former IESG member
No Objection
No Objection
(for -16)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2014-03-21 for -17)
Unknown
Thanks for addressing the prior SecDir comments. Here is a nit to correct as well: Section 6.1 Consider changing from: This section describes an information model that addressing issues specific To: This section describes an information model that addresses issues specific
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -16)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2014-03-26 for -16)
Unknown
I'm not putting a DISCUSS on this, because I have to trust the WG to decide what it's applicability is, but I'm quite concerned that the group is not taking into account energy management systems where power is being supplied by seriously large power systems that need to be monitored. See comments below particularly regarding batteries: 1: The framework also covers monitoring and control of batteries contained in devices. We had this discussion back when the requirements document came out. Characterizing batteries as contained in a device is not right. It is a view of batteries for small devices that might work, but for systems where batteries are a receiver and producer of power, I think it's a bad model. (Similar comment for the description of Components in section 3.) 2: In the definitions: 1. Power Attributes are not intended to be judgmental with respect to a reference or technical value and are independent of any usage context. "judgmental" is the wrong word here. What do you mean? 6.3.4 & 6.3.5 lack any indication of an awareness of internationalization. Are you really saying that *any* characters are allowed except for comma? If so, at least mention that alphanumeric and symbol characters from the entire Unicode repertoire are expected to be reasonable. 6.6.2: o Transitive Power Source relationships SHOULD NOT be established. For example, if an Energy Object A has a Power Source Relationship "Poweredby" with the Energy Object B, and if the Energy Object B has a Power Source Relationship "Poweredby" with the Energy Object C, then the Energy Object A SHOULD NOT have a Power Source Relationship "Poweredby" with the Energy Object C. Why is that? I can certainly imagine a generator powering a UPS, the UPS powering a device, and the generator also powering that device. Are you simply saying that the "Poweredby" relationship gets established and destroyed dynamically? So when the device is being powered by the generator, it is not being powered by the UPS, so the Poweredby relationship between the UPS and the device goes away? (I'm still a bit concerned about load sharing power sources, like two producers on a grid, but maybe that can be finessed.) The SHOULD NOT seems a bit strong. 12.1.4: This is making me very nervous. The only thing I've seen from this group on batteries is the battery mib, and it is completely inappropriate for battery banks for energy systems. The list of battery technologies it talks about are clearly only small batteries for small devices (I don't see gel batteries or absorbed glass mat on the list, though maybe AGMs are suposed to be lead acid), and measurements are only defined in units like milliamperes. That's not a general battery mib, and certainly not one that can be seriously used for batteries in a large scale energy management system. Now this section of the document says that this document is not handling power state sets for batteries. I am not filled with confidence that this group is getting good review from a wide enough audience (outside of the IETF).
Richard Barnes Former IESG member
No Objection
No Objection
(for -16)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -16)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-03-26 for -16)
Unknown
- The 2010 dates in the write-up got me. I assume just typos. - Are energy harvesting devices (e.g. solar panel and charge controller combination) included here or not? I also had to wait until 12.1.4 to read that you're not considering battery powered devices. Doing that at the start would have been way better. - Section 2: RFC 6988 has a terminology section. Why is this one needed too if they are the same? If they are not the same how is this adhering to the requiremnts RFC? - 6.3.4 - alphanumerics for human consumtion in this day and age? That really needs to be UTF8 doesn't it? Is a CSV list an ok thing in UTF8? I dunno myself but I'm sure the Apps ADs will. - 6.3.6: last paragraph there is generating yet another mobile IP problem for the future. Personally, I think you should change that myself. - 6.6.2: I have no clue why you have the three "SHOULD NOT" clauses here and they appear somewhat arbitrary. Why are they needed? (I suspect those are neither necessary nor useful personally.) Same point for 6.6.4.
Benoît Claise Former IESG member
Recuse
Recuse
(for -15)
Unknown