------------------------------------------------------------ IETF-82 EMAN Working Group Meeting Minutes 16-NOV-2011 ------------------------------------------------------------ Room, 101B, 13h00 Legend: ------- [BC] = Benoit Claise [BN] = Bruce Nordman [DR] = Dan Romascanu [KL] = Kerry Lynn [MC] = Mouli Chandramouli [RW] = Rolf Winter [WM] = William Mielke Agenda Bashing: [BN] and [BC] ----------------------------- - Propose to move Energy Aware MIB to just after the requirements, the reason being that doing so helps provide context for the following presentations. [BC] Status: [BC] ------------ - Achieved the five milestones of getting working group documents accepted. - Applicability statement may be accepted today. - We are behind on submitting documents to the area director. - Will revise milestones at the end of the meeting. Terminology: [BC] and [BN] -------------------------- Power state definition: Slides listed the two most favored options from the list and asked which was preferred. [MC] - Will propose merged version on list. Three categories of power quality: 1. Nominal power supply 2. Power quality, deviation from nominal 3. Power usage [MC] - Power Quality has a very specific meaning in some contexts. Power quality mostly encompasses #2. Many of the variables we are considering would be considered more generally additional power characteristics than power quality. [BN] - Proposed to refer to these as Power Characteristics instead of Power Quality to avoid confusion. [BC] - Asks room if Power Characteristics is OK. Notes no objections. Other terms that discussed on the list: - Power State Set - Energy Object Relationship [BN] - Proposed to just continue the discussion on the list. There are three terms which each list two definitions from other sources. How should we handle this? Continue to list multiple definitions? Have only one definition? Have one definition and list the others parenthetically? [DR] - Prefers to have a single definition. OK to list others for informational purposes but working group needs to state clearly what it means by these terms. [WM] - Prefers that EMAN have a single definition. Indicates we may want to discuss whether our definition is known to conflict with the definitions from other standards bodies. [DR] - Clarification. He is fine with using other definitions from other bodies just as long as we are clear which we are using. [RW] - Agrees with Dan. We should not need to redefine something like energy and should adopt one standard definition per term. [BC] - Notes three preferences for a single definition. Polls the room for objections. Finds none. Proposes to select the definitions on the list. Requirements: [MC] ------------------ Status: - Much restructuring has been done. - List of open issues is reducing. - Feels that we are getting closer to completeness. - Discussed the impact of terminology changes and the effects of use cases being defined in the applicability statement. [Technical Difficulties With Slides and WebEx] Previous open issues and resolutions: - Identification: - Reused identifiers from other MIBS - Entity type: - Notes consensus on list to use description field like Entity MIB - Multiple Power State Set Support - Keep the requirement as supporting multiple concurrent power state sets. - Consensus of the room was that the device deal with mapping among the sets it chooses to support. [WM] - Review levels of consensus. Note that we still need to get consensus on the statement of expected behavior. [BC] - Polls the room for their preference. Consensus appears to be support for letting the device maintain an internal power mapping between concurrent Power State sets. Notes that wording must be added to the framework document. - Time series of power values: - Proposal: Instantaneous values should be polled as needed. No requirement to retain history. [WM] - Disagrees and argues that the timing of the data collection is not amenable to the use of polling, and therefore the collection needs to be delegated to the device so that the intervals are consistently measured. [Someone] - We need to support time series data and it will be helpful to be able to correlate values with certain events that have happened at the device. [MC] - Expresses concern about the amount of data required to be stored in the case of small devices. [RW] - Makes the point that having a requirement that the standard enable something does not mean that every device has to implement it. [BC] - Feels we need to rephrase the requirement related to push and/or pull mechanisms. If we want to write something that a push is required then we have to specify something like IPFIX to do the push which is not in the charter. [Misc. discussion about push, pull, and IPFIX and what is really required.] [Brian Tramell] - Time series data is really important for later analysis so we really want this requirement. Favors a push model. Group should go through the Section 5 requirements and should consider which data is more naturally aligned with push vs. pull and see if that helps resolve the differences within the group. - Directional metering of Energy: [Missed it] - Power Notifications: [Missed it] Energy Aware MIB: [BC] ---------------------- - Focuses on Identity, Relationships, and Context - Need to model a UUID for ID purposes. - Two options identified: Version Entity MIB vs. EMAN specific solution. - Problem has been solved. - UUID Solution - Require compliance with a subset of Entity MIB - Utilize entPhysicalUris to avoid iterating Entity MIB spec. - Relationships - Utilize a list of UUIDs in children to model the topologies - Relationships are Optional - Open Issues - Is having entPhysicalUris being read-write a problem from an operational point of view - Do we need a Children list per relationship? [KL] - Do we have something that enforces the fact that children report back to one and only one parent? What about double counting? [BC] - No, we do not limit this. We certainly need to address the issue of double counting for metering, but do we want to limit the number of parents? - Any feedback on the read-write of the UUID issue, as entPhysicalUris is a read-write MIB variable? [Chris ?] - Allowing read-write is likely to cause problems. Why allow it? Inherently bad. What are the downsides when someone overwrites the values? [BC] - It is an issue of timing required for waiting for a new version of Entity MIB. We understand the issue it is just a matter of deciding what to do. Take the discussion to the list. Framework: [BC, since John Parello was not present] --------------------------------------------------- New in this version: - Aligned with the new terminology - Removed the Manufacturer Power States - Provided guidance on how to use the role from the context - Provided information on how to do thresholding - Compliance with the 3 ODVA Energy counters - Push on top of pull? Onus is back on the requirements to state what is needed. - Relationships between EOs - To be stressed in the next version: and EO can be a Device or a Component. - Open Issue: how to deal with PoweredBy and Inlets. [KL] - In other groups, batteries are considered both a load and a source. We should consider having the model take this into account. [BC] - Made some replies. [RW] - Wasn't always clear what relationship to choose. For example, one of the examples it talks about dependency and he expected that to be the relationship but then when he looked it wasn't there. So it is not clear cut. Parent/child isn't clearly defined. Sometimes the framework is very specific and may be introducing requirements. The requirements should in the requirements document. Also the framework was detailed about some aspect of the battery relationships when it is an open issue in the battery MIB. [BC] - Please point out where the framework specifies rules that are not in the requirements. [BN] - Is outlet gang an issue that we want to poll for consensus to get it off the table. [BC] - Has been removed from the requirements and the framework. Should also be removed from the applicability statement. [BC] Section 2 of the Reference Model could be incorporated into the framework. [MC] - Entity MIB also allows you to discover the components of an object like a router or an server. So the components can also be monitored with the framework. Reference Model: [RW] --------------------- - Provides a description of why energy management is different from other management. - Explained more about power interfaces and power distribution topologies. - There is a view that the framework and the reference model need to converge. - Gave his view of the current framework. - Believes that the framework doesn't distinguish between the electrical and the management topologies and feels that this complicates things. - Described the reference model's means of modeling inlets and outlets. - Proposed Integration: - Defines a layered approach. - Highlights some areas which are not addressed by the reference model. [WM] - You mentioned that the reference model doesn't cover some things that the framework does. Why is that? Do you think those things are unimportant or that the framework already covers them adequately for your needs? [RW] - We're saying that this is not the right document to put them in. If they are requirements then they should go in the requirements document. [WM] - OK, that's fine. Do we see the reference model document remaining an independent document or do we see it merging with the framework document? [Some general discussion on why things were not covered.] [WM] - Need to cover batteries in a more general sense. They are not strictly internal components only. [Covers remaining slides] [BC] - Is there something that can be done in the reference model that can't be done in the framework? [BN] - Bidirectional supply issue is problematic in the framework because of the parent/child relationships. Reference model inherently focuses on net energy flow. [MC] - [Didn't catch it.] [BC] - What are the next steps? Make examples to compare and contrast the two cases. [RW] - Conference call between the authors? [BC] - Need to find examples that illustrate the difference between the two. [WM] - Look towards a merger which takes the best parts from both. [BC] - Want to pursue examples which can highlight the differences between the two to facilitate the comparison and decision making. Monitoring MIB: [MC] -------------------- - We have converged on the textual convention for the IANA Power State Set registry. - How to address deprecation of power state sets? - Consider the PWG Power State Set. Proposal: to be requested from IANA when IANA procedure is in place. [Discussion between BC and RW] [RW] - We need further discussion of the EMAN Power State Set definition. We need to discuss the number of states defined and so forth on the email list. [BC] List the open issue on the list. [DR] - Asks for clarification that the IANA proposal will initially include IEEE and other sets and that this can grow over time. [MC] confirms yes. - Directional Metering - Added to the MIB. - Demand Measurement - Do we need a second approach for smaller devices? - Should it be computed on the device or in the EnMS. Battery MIB [RW] ---------------- - Closed Issues: - Writable Thresholds - Alignment with Battery Spec. - Time Estimations (time remaining, etc) - Do we want these in the MIB? - Take this to the list. Applicability Statement: [MC] ----------------------------- - Extended use cases. - Standardized some sections for each use case. - Use Case Patterns - 16 Use Case Definitions - Abstracted into common cases. - Open Issues: - Makes a plea for the need to consider whether the current set of use cases is sufficient. Speak up. - IEC Standards [RW] - Is working with others that are interested in energy and will poll them for input. [BN] - Prefers that we only add new use cases if they generate new requirements. [BC] Does anyone oppose adopting the applicability statement as a working group item? Observes no objections. Wrap Up: -------- Milestones: NEW: Mar 2012 Publish Internet draft on Energy Management Applicability Jul 2012 Submit Internet draft on Energy Management Requirements for publication as Informational RFC Jul 2012 Submit Internet draft on Energy Management Framework for publication as Informational RFC Jul 2012 Submit Internet draft on Energy-aware Networks and Devices MIB for publication as Standard Track RFC Jul 2012 Submit Internet draft on Power and Energy Monitoring MIB for publication as Standard Track RFC Jul 2012 Submit Internet draft on Battery MIB forpublication as Standard Track RFC Jul 2012 Submit Internet draft on Energy Management Applicability for publication as Informational RFC Note: The chairs would like to express their deep appreciation to Bill Mielke for his detailed note-taking.