Skip to main content

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