Subject: [eman] review of draft-ietf-eman-energy-aware-mib-04 (text sections)

From: Juergen Quittek <[email-masked]>
Date: Thu, 8 Mar 2012 08:58:21 +0000

Dear all,

Below please find my review of the text sections of
draft-ietf-eman-energy-aware-mib-04.  I will send comments
on the contained MIB module in a separate email.

    Juergen

Section 1, sentence 1:
  "The EMAN standards provide network administrators with a
   specification for Energy Management."
Why only network administrators? what about network planners,
consultants, manufacturers, etc.  No need to list all of them.
Just delete the first sentence

Section 1, sentence 2:
  "This document defines a subset of a Management Information Base
   (MIB) for use with network management protocols for Energy
   monitoring of Electrical Equipments (for example network devices
   and devices attached to the network.)"
- Here you use the term "Electrical Equipment" before denining it in
the next section. Better avoid it.
- Why are "network devices and devices attached to the network" just
an example?  Which devices not attached to any network do you
intend to monitor? Are they in scope?
- comma missing after "for example"
- swap full stop and closing bracket
Proposal: Just delete the second half of the sentence. the remaining
part says it all:
  "This document defines a subset of a Management Information Base
   (MIB) for use with network management protocols for Energy
   monitoring."
But if you really have devices not attached to any network in scope,
then you should add an explicit statement here, because this is not
what a reader assumes anyway when reading an RFC.

Section 1, sentence 3:
  "This focus of the MIB module specified in this document is on
   monitoring Energy Objects as defined in [EMAN-FMWK]."
- "This focus" -> "The focus"
- Why is the focus of this MIB on monitoring?  I fully disagree.
It is on identification, context assignment, and relationships.
Alls these things are as well useful for monitoring as for control.
I do not see any good reason to restrict their use to monitoring.
- Where does EMAN-FMWK define that this MIB is on monitoring?
If you are right, we should change this in EMAN-FMWK.
Proposal:
  "The focus of this document is on identifying energy objects,
   an reporting on their context and relationships."
   
Section 1.1, sentence 1:
  "This document specifies the Energy-Aware Networks (ENERGY-AWARE-
   MIB ) MIB module."
I have asked this question before: Why is the MIB module called
ENERGY-AWARE-MIB? As said above, it covers identity, context and
relationships, but not any awareness-related concepts. The current
name is just confusing the reader and thus to be changed.
Proposal: replace with "ENERGY-RELATIONS-MIB".

Section 1.1, sentence 2:
  "This document is based on the Energy Management Framework
   [EMAN-FMWK] and meets the requirements specified in the Energy
   Management requirements [EMAN-REQ]."
- Actually, it does not need all the requirements. That's why
there are other MIB modules. What about stating that it
  "... and meets the requirements on identification of powered
   entities, their context and relationships as specified in ..."
   
Section 3: Requirements and Use Cases
There is no point in having this section in the draft.
All it says with respect to this draft has already been
said before in Section 1.

Section 4: Terminology
Not discussed here but in a different draft.  It should be OK to
only include terms actually used in the draft.

Section 5, Figure 1, Class EO Context Information
Attribute eoPowerCategory is introduced by this figure but not
mentioned anywhere in the text before its definition in the MIB
module on page 30.  It would be appropriate to spend a sentence
on this attribute in section 5.2 where the class is described.

Section 5, Figure 1, Class EO Context Information
Attribute eoKeywords: The name of the attribute is OK with me.
Renaming it to eoTags may be more descriptive.

Section 5, first sentence after Figure 1:
  "As displayed in figure 1, there are six different logical groups
   of MIB objects in the ENERGY-AWARE-MIB module"
This is very confusing.  The text speaks about six logical groups,
but the MIB module groups objects much differently in just two
groups.  Please explain the difference or - much better - harmonize
grouping in Figure 1 with grouping in the MIB module.

Section 5.1, second sentence:
  "Every Energy Object MUST implement the unique index,
   entPhysicalIndex, from the ENTITY MIB [RFC4133], which is used
   as index for the primary Energy Object information in the
   ENERGY-AWARE-MIB module."
This is non-sense.  Why does every desktop phone and sensor need
to implement the entPhysicalIndex if it is just a single entity?
You need the entity MIB on devices containing multiple entities,
such as routers with line cards, CPUs, ports, etc.  A small sensor
or a desktop phone can safely survive without splitting itself into
different entities and building a containment tree for them.

Section 5.1, third sentence:
  "Every Energy Object MUST have a printable name"
What means "have"? Does the device need to know about it?
proposal: "have a printable name" -> "have a printable name
assigned to it". 

section 5.1, fourth sentence and following sentences:
  "Energy Objects MUST implement the entPhysicalName object
   specified in the ENTITY-MIB"
  "For the ENERGY-AWARE-MIB compliance, every Energy
   Object instance MUST implement the entPhysicalUris from the
   ENTITY MIB [RFC4133]"
  "Other ENTITY MIB related managed objects, in addition to
   entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133]
   MAY be implemented."
I am not a MIB doctor and do not understand how this would work.
This means that you implement the entPhysicalTable but table rows
would just contain two instead of all columnar objects of the row?
This would look like
entPhysicalTable.EntPhysicalEntry.7 (entPhysicalName)
entPhysicalTable.EntPhysicalEntry.18 (entPhysicalUris)

What you are saying is "Implement as many objects in the
entPhysicalTable as you like, but at least these two, then you are
compliant with the ENERGY-AWARE-MIB.  Probablyyou would not be
compliant with the ENTITY-MIB, if you do not implement all.

Section 5.1, fourth paragraph, lines 6-7:
  "Note that the entPhysicalUris, as inherited from the ENTITY-MIB,"
What means "inherited" in this context?  I do not know of any
inheritance mechanism in SMI.

Section 5.1, 7th paragraph:
  "When an Energy Object Parent acts as a Power Aggregator or a
   Power Proxy, the Energy Object Parent and its Energy Object
   Child/Children MUST be members of the same Energy Management
   Domain, specified by the eoDomainName MIB Object."
I disagree.  Why should we strictly forbid aggregating two domains?
This is an unnecessary limitation of potential applications of this
MIB module.  What would you win by applying this limitation?

Section 5.1, 8th paragraph:
  "Each Energy Object MUST belong to a single Energy Management
   Domain or in other words, an Energy Object cannot belong to more
   than one Energy Management Domain."
I disagree again.  Why this limitation?  Why do you unnecessarily
restrict potential applications of this MIB module.

Section 5.1, 8th paragraph, lines 6-8:
  "The Energy Management Domain should map 1-1 with a metered or
   sub-metered portion of the site."
You say "the site".  This concept has not been mentioned before.
Please define it helping reader to understand what you want to say.

Section 5.1, 8th paragraph, lines 8-9:
  "The Energy Management Domain MUST be configured on the Energy
   Object Parent."

Section 5.1, 8th paragraph, last sentence:
  "he Energy Object Children MAY
   inherit their domain parameters from the Energy Object Parent or
   the Energy Management Domain MAY be configured directly in an
   Energy Object Child."
What are "domain parameters"?  Please explain.  I am aware of a
single one only, the domain name. Are there others?
The sentence states children MAY inherit the domain or MAY have it
configured directly.  What means "inherit"?  The children ask their
parents and set it? Parents configure their children? Children are
not configured at all, because the parent knows about it?

Section 5.1, last paragraph:
  "The eoMgmtMacAddress, eoMgmtAddress, eoMgmtAddressType, and
   eoMgmtDNSName MIB objects SHOULD be implemented for Energy
   Object.
This is the first time these three objects are mentioned in the
text.  It would be desirable to first have a short sentence on
explaining what they are before discussing constraints on them.
Particularly, a reader might like to know what a "management address"
is.

Section 5.2
All context attributes are discussed here except for eoPowerCategory.
Looks like a good idea to mention it.

Section 5.2, second paragraph. first sentence:
  "An Energy Object can provide a eoImportance value in the range
   of 1..100 ..."
"a eoImportance" -> "an eoImportance"
What means "*can* provide"? According to the MIB spec the implementation
of the object is mandatora and there is not value specified in the
object description for "empty", "unknown" or "don't care".  So it's
rather a "MUST" than a "can".

Section 5.3, first sentence:
  "While the entPhysicalIndex is the primary index for all MIB
   objects in the ENERGY-AWARE-MIB module, the Energy Management
   Systems (EnMS) must be able to make the link with the
   identifier(s) in other supported MIB modules."

Section 5.3, second sentence:
"values of pethPsePortIndex and pethPsePortGroupIndex" ->
"values of pethPsePortIndex and pethPsePortGroupIndex, respectively"

Section 5.4 & 5.5
Here I have a larger issue that I will send in a separate email.

Section 6
This section mainly consists of a figure of the MIB structure.
It would be desirable to move this further up.  Currently, the
text first discusses all objects in the MIB and then in the end
shows how they are organized.  Having the structure known when
reading about the indivicual objects would be very useful.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 12 Mar 2012 14:00:52 +0100

Hi Juergen,

Let me just address one issue in your email.
> different entities and building a containment tree for them.
We need anyway a index in the MIB table.
The message is simply: same the same value as the EntityPhysicalIndex.
See the next comment.
> entPhysicalTable.EntPhysicalEntry.18 (entPhysicalUris)
Correct.
> compliant with the ENERGY-AWARE-MIB.
Yes.
> Probablyyou would not be
That's correct.
However, if you would like/have to implement it (let's say you want the 
temperature as Bruce requested), then you have the right basis to 
implement the ENTITY-SENSOR-MIB

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 12 Mar 2012 15:35:51 +0000

Hi Benoit,

This way we would promote non-compliant implementations of the Entity MIB?
Do we want this?  Have you checked this with the MIB doctors?

Thanks,
    Juergen

---

From: Ira McDonald <[email-masked]>
Date: Mon, 12 Mar 2012 11:53:01 -0400

Hi,

17 years ago, the Printer MIB v1 (RFC 1759) foolishly
downgraded IETF MIB-II and IETF Host Resources MIB
requirements for compliance.

Because of legacy products, this foolishness was preserved
8 years ago in Printer MIB v2 (RFC 3805) - mea culpa (as
one of the PMv2 editors).

So I've spent the past 17 years trying to convince printer
vendors that it's a *bad* idea to downgrade MIB-II and
Host Resources MIB and implement subsets of their actual
conformance requirements.

This was a topic of lively discussion w/ the MIB Doctors
before publication of Printer MIB v2 - no one was happy.

Please don't go there in the EMAN MIBs.

A new MIB may reasonably *expand* conformance for some
other MIB.  But it is inherently unsuitable to *reduce* the
conformance requirements for the some other MIB.  This
can't be expressed in AGENT-CAPABILITIES statements
in any meaningful way.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Mar 12, 2012 at 11:35 AM, Juergen Quittek <[email-masked]> wrote:

> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 14 Mar 2012 04:28:35 -0500

Juergen,

Thanks very much for your detailed review and comments. 

Replies inline. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Thursday, March 08, 2012 2:28 PM
To: eman mailing list
Subject: [eman] review of draft-ietf-eman-energy-aware-mib-04 (text
sections)

Dear all,

    Juergen

Section 1, sentence 1:
[ycm] Yes, done. 

Section 1, sentence 2:
[ycm] 
[ycm] Yes, corrected the text. 
[ycm] In addition to network devices; it may also be possible to extend
to devices with a network interface.

Section 1, sentence 3:
[ycm] yes. Corrected - this MIB focuses on identification, context and
relationship

Section 1.1, sentence 1:
[ycm] we have used the name - ENERGY-OBJECT-CONTEXT-MIB

Section 1.1, sentence 2:
[ycm] yes, your are correct - this document meets a subset of the
requirements 
   
[ycm] Yes, the duplicate content sentences are deleted and the section
is summarized. 

Section 4: Terminology
Not discussed here but in a different draft.  It should be OK to
only include terms actually used in the draft.
[ycm] Right now, we have a place holder for the terminology. Once there
is agreement at the WG on the terms 
[ycm] we can define only the terms used in the draft. 

[ycm] thanks. We have a short definition of eoPowerCategory

Section 5, Figure 1, Class EO Context Information
Attribute eoKeywords: The name of the attribute is OK with me.
Renaming it to eoTags may be more descriptive.
[ycm] Thanks. We feel that eoKeywords would be more appropriate and is
commonly used in search. 

[ycm] Thanks. The text corrected and the OID tree and UML diagram are
corrected. 

[ycm] We have modified the text. 
[ycm] This issue is discussed on the mailing list and we have listed
this an open issue

[ycm] thanks. It is corrected. 

[ycm] This issue is discussed on the mailing list and we have listed
this an open issue

[ycm] Text corrected - what is meant is if we reuse entPhysicalUris - it
is a read/write object. 

Section 5.1, 7th paragraph:
  "When an Energy Object Parent acts as a Power Aggregator or a
   Power Proxy, the Energy Object Parent and its Energy Object
   Child/Children MUST be members of the same Energy Management
   Domain, specified by the eoDomainName MIB Object."
I disagree.  Why should we strictly forbid aggregating two domains?
This is an unnecessary limitation of potential applications of this
MIB module.  What would you win by applying this limitation?
[ycm] Yes, in principle that can be true.  We do not think this is a
restrictive assumption.  
[ycm] To facilitate easier management, we need to consider some
assumptions and this is a useful rule. 

[ycm] Same as before

Section 5.1, 8th paragraph, lines 6-8:
  "The Energy Management Domain should map 1-1 with a metered or
   sub-metered portion of the site."
You say "the site".  This concept has not been mentioned before.
Please define it helping reader to understand what you want to say.
[ycm] Site word has been removed.  Energy management domain should match
with the metered network. 

[ycm] There can be common parameters across a domain - context,
keywords,... 

[ycm] Thanks. The text has been reorganized.  

Section 5.2
All context attributes are discussed here except for eoPowerCategory.
Looks like a good idea to mention it.
[ycm] Yes, it is corrected. 

[ycm] Thanks. Corrected. 

[ycm] Thanks. Corrected.

Section 6
[ycm] Thanks. Corrected.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 14 Mar 2012 11:55:08 +0100

Ira, Juergen,

Let me try to summarize the situation, and give some history here (and 
btw, redo the discussions we've having at the last two IETF meetings... ).

-  EMAN framework is based on Energy Object Relationship between Energy 
Objects
-  To uniquely identify Energy Objects, we need UUIDs
-  We could define UUIDs in [EMAN-CONTEXT-AWARE], but UUIDs are not 
Energy Object specific. Granted.
-  Ideally, we wanted a real UUID in an ENTITY-MIB version 4, but, even 
if discussed, no work was done in that direction
- Then entPhysicalUris (from the ENTITY-MIB) was proposed as a way out 
of this solution. See 
http://www.ietf.org/mail-archive/web/eman/current/msg00910.html
- For a switch, a router, or even a server, it would make sense to 
implement the full ENTITY-MIB.
However, we received the feedback that standalone small devices don't 
want to implement the full ENTITY-MIB. Granted.
- Hence the proposal to require the implementation of just three objects 
from the ENTITY-MIB
Note: This was selected as the solution out of two bad choices
     1. duplicate OIDs in the EMAN MIB modules, while they're not energy 
specific
     2. require the implementation of 3 objects, with the non-compliant 
implementations of the Entity MIB

See the IETF 81 meeting minutes 
(http://www.ietf.org/proceedings/81/minutes/eman.txt)

    - Some discussion occurred among [BC], [JS], and [WH].
       [BC] Some more objects might be referred to the ENTITY-MIB, with a minimum compliance
       statement for the ENTITY-MIB, specficically for EMAN. For example, the pmName,
       which refers to the entPhysicalName if the ENTITY-MIB is supported.

    - [DR]: Question about whether we need to update the Entity MIB with the UUID.
       His point is that we need to plan for this.  What is the preference?  [BC]
       makes the point that to do it right it goes in the ENTITY MIB; to do it quick
       it goes in the EMAN pmIndex.

See the IETF 82 meeting minutes 
(http://www.ietf.org/proceedings/82/minutes/eman.txt)

Hopefully, some MIB doctors on this list will share their view.

Regards, Benoit.

> mailto:[email-masked] <mailto:[email-masked]>
> On Mon, Mar 12, 2012 at 11:35 AM, Juergen Quittek <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Benoit,
>
>     On 12.03.12 13:00, "Benoit Claise" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >Hi Juergen,
>     >
>     [email-masked] <mailto:[email-masked]>