Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Jan 2014 17:20:13 +0100

Hi Juergen,

Thanks for your thorough review.
> Dear all,
>
> Below please find my comments on draft-ietf-eman-energy-aware-mib-13 titled "Energy Object Context MIB". I will send comments on draft-ietf-eman-energy-monitoring-mib-08 in a separate message.
>
> ==================
> Technical comments:
> ==================
>
> 1) Section 5.1, 3rd paragraph: Since you are already very precise about this MUST, I would add that the name MUST NOT have length zero.
Not sure this is correct. RFC 6933 allows a zero-length string. See the 
second paragraph below.

entPhysicalName OBJECT-TYPE
     SYNTAX      SnmpAdminString
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
             "The textual name of the physical entity.  The value of this
             object should be the name of the component as assigned by
             the local device and should be suitable for use in commands
             entered at the device's `console'.  This might be a text
             name (e.g., `console') or a simple component number (e.g.,
             port or module number, such as `1'), depending on the
             physical component naming syntax of the device.

             If there is no local name, or if this object is otherwise
             not applicable, then this object contains a zero-length
             string.

             Note that the value of entPhysicalName for two physical
             entities will be the same in the event that the console
             interface does not distinguish between them, e.g., slot-1
             and the card in slot-1."
     ::= { entPhysicalEntry 7 }

However, this sentence below is badly expressed

   Every Energy Object MUST have a printable name assigned to it.

This sentence actually means that if an assigned name is used, it must 
be a printable one.
However, I wonder if this that sentence is needed at all, because we 
overrule the entPhysicalName definition from the ENTITY-V4 RFC.

On top of that, with SnmpAdminString, we should be good, no?

from http://www.ietf.org/rfc/rfc3411.txt,
SnmpAdminString ::= TEXTUAL-CONVENTION
     DISPLAY-HINT "255t"
     STATUS       current
     DESCRIPTION "An octet string containing administrative
                  information,_preferably in human-readable form_.

                  To facilitate internationalization, this
                  information is represented using the ISO/IEC
                  IS 10646-1 character set, encoded as an octet
                  string using the UTF-8 transformation format
                  described in [RFC2279].

                  Since additional code points are added by
                  amendments to the 10646 standard from time
                  to time, implementations must be prepared to
                  encounter any code point from 0x00000000 to
                  0x7fffffff.  Byte sequences that do not
                  correspond to the valid UTF-8 encoding of a
                  code point or are outside this range are
                  prohibited.

                  The use of control codes should be avoided.

                  When it is necessary to represent a newline,
                  the control code sequence CR LF should be used.
                  The use of leading or trailing white space should
                  be avoided.

                  For code points not directly supported by user
                  interface hardware or software, an alternative
                  means of entry and display, such as hexadecimal,
                  may be provided.

                  For information encoded in 7-bit US-ASCII,
                  the UTF-8 encoding is identical to the
                  US-ASCII encoding.

                  UTF-8 may require multiple bytes to represent a
                  single character / code point; thus the length
                  of this object in octets may be different from
                  the number of characters encoded.  Similarly,
                  size constraints refer to the number of encoded
                  octets, not the number of characters represented
                  by an encoding.

                  Note that when this TC is used for an object that
                  is used or envisioned to be used as an index, then
                  a SIZE restriction MUST be specified so that the
                  number of sub-identifiers for any object instance
                  does not exceed the limit of 128, as defined by
                  [RFC3416].

                  Note that the size of an SnmpAdminString object is
                  measured in octets, not characters.
                 "
     SYNTAX       OCTET STRING (SIZE (0..255))

Proposal, to make it clear that printable names are really a plus:
OLD:
	 "Every Energy Object MUST have a printable name assigned to it"
NEW:
	 "While entPhysicalName does allow zero-length name, every Energy
          Object should have a printable name assigned to it"

>
> 2) Section 5.1, one but last 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." This is more strict than in the framework where we say an EO "should" not belong to more than one domain. However, as we have discussed several times, there are management systems that use more than one domain (different to EnergyWise). I do not see a good reason to declare that their model is wrong. Thus, we can recommend "make it as EnergWise from Cisco does it" with the "should" clause that we have in the framework, but we should not fully exclude other solutions with a "must" clause. See also comment 7).
Thanks for catching this discrepancy.
The framework mentions on one side:

         The Energy Object (Class) contains a string attribute to
         indicate membership in an Energy Management Domain.

It's true that this framework sentence contradicts this:

         An Energy Object should be a member of a single Energy
         Management Domain therefore one attribute is provided.

This last sentence doesn't reflect what was discussed at
http://www.ietf.org/mail-archive/web/eman/current/msg02033.html

    JP : We've discussed this at length and the approach we chose was to
    use a vector for the keywords to allow for further defining context
    you describe. We proposed scalar for the PRIMARY category and the
    PRIMARY role. 

And, most importantly, 
http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which 
is the outcome of the authors call, supervised by Nevil:

    *** Scalar vs Vector
            Category  - overloaded if vectore { cons, prod, meter,
    distributor, store }
                 Primary is better received
             ex: car { biz, pleasure, commute }
            Role - need semantic not vector
            Location? (new) - clearly not vector but semantic like
    rfc4776 better geo-priv
            Domain - no problem we discussed and went with single
    Experience in filed is that scalar was only needed for these.
    ref point lldp : brad

The framework should correct this sentence:
OLD:

         An Energy Object should be a member of a single Energy
         Management Domain therefore one attribute is provided.

NEW:

         An Energy Object must be a member of a single Energy
         Management Domain therefore one attribute is provided.

>
> 3) Section 5.3, 2nd and 3rd paragraph:
> Both paragraphs need more explanation and you need to make them consistent with the text in the MIB modules. For LLDP you say "If the LLDP MIB is implemented". Why don't you have a similar statement for the PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP agents, for example, if they are just a power interface. And it is not specified which of the potentially numerous instances of lldpLocPortNum objects of a device should be reported.
Ack, will provide some new text
>
> 4) Section 5.4, 4th paragraph:
> "Since the communication between the Energy Objects may not be
> SNMP and is left to the choice of the device manufacturer, an
> Energy Object can have additional MIB objects that can be used
> for easier identification by the EnMS."
> Two comments on this sentence:
> A) It is not very obvious if SNMP is not available, it makes sense to use MIB objects. Please clarify this.
> B) Please note that the choice is not only with the manufacturer. Even if the manufacturer builds in SNMP, the operator may choose to disable it ;-)
This is a badly written sentence.
Proposal: remove

    "Since the communication between the Energy Objects may not be
    SNMP and is left to the choice of the device manufacturer"

>
> 5) Section 6, DESCRIPTION clause of object eoEthPortIndex:
> What "attached device" are you talking about?
> Why is it relevant for the specification of this object, if that a certain MIB module "should" be implemented on that device? Does it make any different for the DESCRIPTION of this object whether or not this MIB module is implemented on the attached device? I do not see why and thus recommend removing the statement "PoE MIB should be instantiated on the device."
New text will be proposed.
>
> 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName:
> There may be more than one DNS name associated to a single IP address:
> "the DNS name" -> "a DNS name"
fixed
>
> 7) Section 6, DESCRIPTION clause of object eoDomainName:
> Please insert as second sentence: "If the energy object has been assigned to multiple domains, then they are represented in this object as comma-separated list.", see comment 2).
See point 2.
>
> 8) Section 6, SYNTAX clause of object eoPowerCategory:
> Some devices match more than one category, for example a UPS is a store and a distributor at the same time, and to be precise, also a consumer. A PoE Switch is a consumer and a distributor, some devices switch between consumer and producer, etc. We can support all of this if we change the syntax from INTEGER to BITS.
See point 2, for the justification, discussed at the [EMAN-FMWK] time, 
on why not to do this.
>
> 9) Section 6, DESCRIPTION clause of object eoAlternateKey:
> There is a contradiction between having this object with MAX-ACCESS read-write and stating " This object specifies a manufacturer defined string". If the manufacturer defines the string, there is no need to write it. I suggest allowing the operator to set the value of this document.
The use of the "manufacturer" word is a poor choice.
This corresponds to section 5.3:

         The eoAlternateKey alternate key object specifies a manufacturer
         defined string that can be used to identify the Energy Object.
         Since an EnMS may need to correlate objects across management
         systems, this alternate key is provided to facilitate such a
         link.  This optional value is intended as a foreign key or
         alternate identifier for a manufacturer or EnMS to use to
         correlate the unique Energy Object Id in other systems or
         namespaces. If an alternate key is not available or is not
         applicable then the value is the zero-length string.

Proposal: change to "alternate"

In section 5.3
OLD:

         The eoAlternateKey alternate key object specifies a manufacturer
         defined string that can be used to identify the Energy Object.
NEW:
         The eoAlternateKey object specifies an alternate key string
         that can be used to identify the Energy Object.

OLD:

       eoAlternateKey OBJECT-TYPE
             SYNTAX          SnmpAdminString
             MAX-ACCESS      read-write
             STATUS          current
             DESCRIPTION
                "This object specifies a manufacturer defined string that
                can be used to identify the Energy Object.

NEW:

       eoAlternateKey OBJECT-TYPE
             SYNTAX          SnmpAdminString
             MAX-ACCESS      read-write
             STATUS          current
             DESCRIPTION
                "This object specifies an alternate key string

>
> 10) Section 6, DESCRIPTION clause of object eoRelationID:
> I recommend adding a sentence to the DESCRIPTION clause, that preferable the value of an entPhysicalUUID from the Entity MIB should be used for values of this object.
ok.
>
> 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module:
> The dependence of compliance with entity4CRCompliance is stated in the GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a dependency on entity4CRCompliance  independent of which group is implemented. Hence, these statements need to be moved from the GROUP DESCRIPTION clauses to the module compliance DESCRIPTION clauses of energyObjectContextMIBFullCompliance and energyObjectContextMIBReadOnlyCompliance.
That makes sense.
>
> 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module:
> We state in other places that implementation of the Entity MIB compliant with entity4CRCompliance is a must. But in the conformance section of the ENERGY-OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as "should". This need to be changed to a "must" or "required."
Good catch.
>
> 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship:
> For interoperability, the description need to be clear. As this TC is stated, there are two points unclear to me:
> A) " The enumeration 'poweredBy' is applicable if the
>         Energy Object A is poweredBy Energy Object B.
>         The enumeration 'powering' is applicable if the
>         Energy Object A is powering Energy Object B."
> If the TC is used, how do I know which object is A and which is B? Is it that the DESCRIPTION clauses of objects of this type must refer to object A and object B?
OLD:

         IANAEnergyRelationship ::= TEXTUAL-CONVENTION
             STATUS            current
             DESCRIPTION
                     "An enumerated value specifies the type of
                      relationship between Energy Objects.

NEW:

         IANAEnergyRelationship ::= TEXTUAL-CONVENTION
             STATUS            current
             DESCRIPTION
                     "An enumerated value specifying the type of
                     relationship between an Energy Object A, on which
                     the relationship is specified, with the Energy Object B,
                     characterized by the UUID."

> B) "if the Energy Object A is aggregating Energy Object B"
> There is no place in this document where there is explained what aggregating means.
Part of section 5.4, we refer to [EMAN-FMWK], which defines the 
aggregation relationship as a summation. I guess you want some more text 
in this section 5.4?
> =================
> Editorial comments:
> =================
All these will be taken care of.

Thanks again.

Regards, Benoit.
>
> 14) Abstract, last two lines:
> "relationships between reporting devices, remote devices, and monitoring devices.": The enumeration of "reporting devices", "monitoring devices", and "remote devices" is inappropriate because it does not reflect the list of relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy.
>
> 15) Section 1. Introduction, 2nd paragraph, last two lines:
> "Identification" -> "identification"
> "Context" -> "context"
> "Relationships" -> "relationships"
>
> 16) Section 1.1, 3rd paragraph, line 1:
> "A second MIB module required by the [EMAN-FMWK]": There is no MIB module required by the EMAN framework. It seems you wanted to say: "A second MIB module meeting EMAN requirements given by [RFC6988]".
>
> 17) Entire Section 3
> This section is completely redundant. It mainly repeats sentences of section 1.1. Remove this section and merge sentences you want to keep into section 1.1
>
> 18) Section 5, 3rd paragraph, first sentence:
> The sentence is not grammatically correct, please fix. Also semantic correction seems to be needed. You don't mention "identification" as focus of the first table.
>
> 19) Section 5, sentence before Figure 1:
> "The following UML diagram illustrates the relationship of the
> MIB objects in the eoTable, eoRelationTable that describe the
> identity, context and relationship of an Energy Object."
> You should mention that you UML diagram furthermore contains objects from the Entity MIB.
>
> 20) Section 5, figure 1:
> There is a dotted line at the lower left that goes nowhere. Please cut it.
>
> 21) Section 5, grouping of MIB objects is inconsistent.
> In Figure 1 you have three groups: "Context", "Identification", "Relationships", where "Identifications" has three subgroups. The sentence below the figure emphasizes this grouping. However, the following subsections 5.1-5.4 are grouped differently. 5.1 is titled "Identification" but covers only a third of the objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure 1 covering context information. Section 5.3 covers PoE and LLDP identification. Sections 5.4 is called "Relationships" but covers not just the objects under "Relationships" in Figure 1, but also objects from under "Identification" in Figure 1. Here is a clean-up needed. Please split the last sentence from section 5.4. It firs much better in section 5.3.
>
> 22) Section 5, enumeration under Figure 1:
> Please note that subsection 5.5 is not another group of MIB objects but refers to objects in subsection 5.1. The sentence above the enumeration implies that each numbered item would be a group of objects.
>
> 23) Section 5.1, 2nd paragraph, line 7:
> What is "primary Energy Object information"?
>
> 24) Section 5.4, 2nd paragraph, last sentence:
> "It is important to notice, that it is possible that" -> "Obviously,"
> "not have an" -> "not have any"
>
> 25) Section 5.4, 4th paragraph
> The entire paragraph is in the wrong subsection. It rather belongs to subsection 5.1 or 5.3.
>
> 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex:
> See comment 5). There is a full stop missing at the end of the second sentence.
>
> 27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup:
> The comment "Note that object eoRelationIndex is not included since it is not-accessible" is not really needed. Almost every Conformance section has such objects and usually this comment is omitted.
>
> Cheers,
>      Juergen
>
>
>> -----Original Message-----
>> From: eman [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>> Sent: Montag, 16. Dezember 2013 16:56
>> To: eman mailing list
>> Subject: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08
>> and draft-ietf-eman-energy-aware-mib-13
>>
>>
>> 	As agreed at the last WG meeting, with the EMAN Framework
>> completing its WG LC the chairs would like to initiate a WG LC on draft-ietf-
>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13.
>> The WG LC will end on Dec 30 at 8AM EDT.
>>
>> 	Thank you,
>>
>> 	Nevil and Tom
>>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
> .
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Jan 2014 17:23:01 +0100

Jürgen,
> Dear all,
>
> There are two more comments on draft-ietf-eman-energy-aware-mib-13 that I missed to include in my previous email.
>
> One is editorial and one is technical:
>
> Editorial: MIB modules description
> It is just once mentioned that there are two MIB modules in this draft (Section 1.1, first sentence. The draft starts discussing the ENERGY-OBJECT-CONTEXT-MIB module and sometimes uses "this MIB modules" to refer to it. When the discussion of the other MIB module starts in the middle of section 5.4 it would be helpful adding a statement reminding the reader that this module is included in the draft as well. For example by changing in section 5.4, 3rd paragraph
> OLD
>          The IANA Energy Relationship MIB module specifies the first
>          version of the IANA-maintained definitions of relationships
> NEW
>          The IANA Energy Relationship MIB module in Section 6 below specifies the first
>          version of the IANA-maintained definitions of relationships
Yes.
>
> Technical: object eoPowerInterfaceType
> I wonder why object eoPowerInterfaceType is included in the ENERGY-OBJECT-CONTEXT-MIB and not in the ENERGY-OBJECT-MIB itself. This object does not provide context, identity, or relationship information, but rather a technical property of a power interface, such as the nominal voltage or the number of AC phases. Why is it in this MIB module. Wouldn't it fit much better in the other one?
I guess it depends on how we look at inlet/outlet: is this context 
information or technical property.
No strong feeling about that one. What do the others think?

Regards, Benoit

>> From: eman [mailto:[email-masked]] On Behalf Of Juergen Quittek
>> Sent: Montag, 30. Dezember 2013 13:05
>> To: eman mailing list
>> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-
>> 08 and draft-ietf-eman-energy-aware-mib-13
>>
>> Dear all,
>>
>> Below please find my comments on draft-ietf-eman-energy-aware-mib-13
>> titled "Energy Object Context MIB". I will send comments on draft-ietf-eman-
>> energy-monitoring-mib-08 in a separate message.
>>
>> ==================
>> Technical comments:
>> ==================
>>
>> 1) Section 5.1, 3rd paragraph: Since you are already very precise about this
>> MUST, I would add that the name MUST NOT have length zero.
>>
>> 2) Section 5.1, one but last 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." This is more strict
>> than in the framework where we say an EO "should" not belong to more than
>> one domain. However, as we have discussed several times, there are
>> management systems that use more than one domain (different to
>> EnergyWise). I do not see a good reason to declare that their model is wrong.
>> Thus, we can recommend "make it as EnergWise from Cisco does it" with the
>> "should" clause that we have in the framework, but we should not fully exclude
>> other solutions with a "must" clause. See also comment 7).
>>
>> Both paragraphs need more explanation and you need to make them consistent
>> with the text in the MIB modules. For LLDP you say "If the LLDP MIB is
>> implemented". Why don't you have a similar statement for the PoE MIB? You
>> talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP
>> agents, for example, if they are just a power interface. And it is not specified
>> which of the potentially numerous instances of lldpLocPortNum objects of a
>> device should be reported.
>>
>> "Since the communication between the Energy Objects may not be SNMP and is
>> left to the choice of the device manufacturer, an Energy Object can have
>> additional MIB objects that can be used for easier identification by the EnMS."
>> B) Please note that the choice is not only with the manufacturer. Even if the
>> manufacturer builds in SNMP, the operator may choose to disable it ;-)
>>
>> Why is it relevant for the specification of this object, if that a certain MIB
>> module "should" be implemented on that device? Does it make any different
>> for the DESCRIPTION of this object whether or not this MIB module is
>> implemented on the attached device? I do not see why and thus recommend
>> removing the statement "PoE MIB should be instantiated on the device."
>>
>> Please insert as second sentence: "If the energy object has been assigned to
>> multiple domains, then they are represented in this object as comma-separated
>> list.", see comment 2).
>>
>> Some devices match more than one category, for example a UPS is a store and
>> a distributor at the same time, and to be precise, also a consumer. A PoE
>> Switch is a consumer and a distributor, some devices switch between consumer
>> and producer, etc. We can support all of this if we change the syntax from
>> INTEGER to BITS.
>>
>> There is a contradiction between having this object with MAX-ACCESS read-
>> write and stating " This object specifies a manufacturer defined string". If the
>> manufacturer defines the string, there is no need to write it. I suggest allowing
>> the operator to set the value of this document.
>>
>> I recommend adding a sentence to the DESCRIPTION clause, that preferable
>> the value of an entPhysicalUUID from the Entity MIB should be used for values
>> of this object.
>>
>> The dependence of compliance with entity4CRCompliance is stated in the
>> GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a
>> dependency on entity4CRCompliance  independent of which group is
>> implemented. Hence, these statements need to be moved from the GROUP
>> DESCRIPTION clauses to the module compliance DESCRIPTION clauses of
>> energyObjectContextMIBFullCompliance and
>> energyObjectContextMIBReadOnlyCompliance.
>>
>> We state in other places that implementation of the Entity MIB compliant with
>> entity4CRCompliance is a must. But in the conformance section of the ENERGY-
>> OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as
>> "should". This need to be changed to a "must" or "required."
>>
>> If the TC is used, how do I know which object is A and which is B? Is it that the
>> DESCRIPTION clauses of objects of this type must refer to object A and object
>> B?
>> "relationships between reporting devices, remote devices, and monitoring
>> devices.": The enumeration of "reporting devices", "monitoring devices", and
>> "remote devices" is inappropriate because it does not reflect the list of
>> relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy.
>>
>> "A second MIB module required by the [EMAN-FMWK]": There is no MIB
>> module required by the EMAN framework. It seems you wanted to say: "A
>> second MIB module meeting EMAN requirements given by [RFC6988]".
>>
>> 17) Entire Section 3
>> This section is completely redundant. It mainly repeats sentences of section 1.1.
>> Remove this section and merge sentences you want to keep into section 1.1
>>
>> The sentence is not grammatically correct, please fix. Also semantic correction
>> seems to be needed. You don't mention "identification" as focus of the first
>> table.
>>
>> "The following UML diagram illustrates the relationship of the MIB objects in
>> the eoTable, eoRelationTable that describe the identity, context and
>> relationship of an Energy Object."
>> In Figure 1 you have three groups: "Context", "Identification", "Relationships",
>> where "Identifications" has three subgroups. The sentence below the figure
>> emphasizes this grouping. However, the following subsections 5.1-5.4 are
>> grouped differently. 5.1 is titled "Identification" but covers only a third of the
>> objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure
>> 1 covering context information. Section 5.3 covers PoE and LLDP identification.
>> Sections 5.4 is called "Relationships" but covers not just the objects under
>> "Relationships" in Figure 1, but also objects from under "Identification" in
>> Figure 1. Here is a clean-up needed. Please split the last sentence from section
>> 5.4. It firs much better in section 5.3.
>>
>> Please note that subsection 5.5 is not another group of MIB objects but refers
>> to objects in subsection 5.1. The sentence above the enumeration implies that
>> each numbered item would be a group of objects.
>>
>> The comment "Note that object eoRelationIndex is not included since it is not-
>> accessible" is not really needed. Almost every Conformance section has such
>> objects and usually this comment is omitted.
>>
>> Cheers,
>>      Juergen
>>
>>
>> completing
>>> its WG LC the chairs would like to initiate a WG LC on draft-ietf-

---

From: Benoit Claise <[email-masked]>
Date: Tue, 21 Jan 2014 11:05:08 +0100

Hi Jürgen,
> Dear all,
>
> Here are my last two comments for this WGLC. Both concerns the conformance section of the ENERGY-OBJECT-MIB module in draft-ietf-eman-energy-monitoring-mib-08:
>
> 1. I may have missed a point here: Why is the Entity MIB not mandatory anymore to implement? It is just two additional objects, since entPhysicalIndex from this MIB is needed anyway. Particularly, we considered the UUID provided by this MIB essential for our framework.
I don't understand this point. We have right now

         Every Energy Object MUST implement the unique index,
         entPhysicalIndex, entPhysicalName and entPhysicalUUID from the
         ENTITY MIB [RFC6933]. Module Compliance with respect to
         entity4CRCompliance of ENTITY-MIB should be supported which
         require a limited number of objects supported (entPhysicalClass,
         entPhysicalName, entPhysicalUUID).

Btw, we miss the entPhysicalClass in the first setence. Will be corrected.
Or maybe you meant that we must have a MUST in the second sentence?

         Every Energy Object MUST implement the unique index,
         entPhysicalIndex, entPhysicalClass, entPhysicalName,
         and entPhysicalUUID from the ENTITY MIB [RFC6933].
         Module Compliance with respect to entity4CRCompliance of
         ENTITY-MIB MUST be supported which require a limited number
         of objects supported (entPhysicalIndex, entPhysicalClass,
         entPhysicalName, entPhysicalUUID).

Note: these 2 sentences are somehow redundant. We might improve this if you want.

>
> 2. Why is the module compliance dependency on the Entity MIB repeated in the DESCRIPTION clauses of all optional groups within a MODULE-COMPLIANCE declaration? I think It is fully sufficient to have it stated in the top DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make any sense to repeat it for optional groups?
Yes.

Regards, Benoit

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 21 Jan 2014 12:40:40 +0000

Hi  Georgios,

We are addressing the comments with respect to draft-ietf-eman-energy-aware-mib-13.

Replies inline.

Thanks
Mouli

Hi all,

Sorry for the delay on providing comments on time for the WGLC of draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13.

Here are my comments!

Many of the comments that I wanted to send are similar to the ones sent by Juergen Quittek. Therefore, I will send only the ones that are different!

=> Regarding: draft-ietf-eman-energy-aware-mib-13:

Comment_1: Section 5, page 6 shows the entries/attributes  (MIB objects) of the eaTable and eoRelationTable. In Figure 1 the UML diagram illustrates the relationship of the MIB objects in the eatable and eoRelationTable. However not all entries (MIB objects) depicted in eaTable and eoRelationTable (page 6) are shown in the UML diagrams. Please elaborate on this in the text.

ycm>>  The UML diagram has been updated.

Comment_2: In section 5.2, page 20 is mentioned: “The Energy Object can be classified as consuming power or supplying power to other devices or that Energy Object can perform both of those functions, ..”. However, in the formal MIB definition on page 20, eoPowerCategory can get the values: consumer (0), producer(1), meter(2), distributor(3) or store(4). From what I can see no value is provided for the situation that the energy object can perform both functions consumer and producer.

 ycm>> This point has been discussed at length  and the approach that we have taken is to use a vector for the Keywords to allow for further defining context you describe. We proposed scalar for the PRIMARY category.
 ycm>>   Please refer to http://www.ietf.org/mail-archive/web/eman/current/msg02033.html

==============================

=> Regarding draft-ietf-eman-energy-monitoring-mib-08:

Comment_1:Section 5: It is not clear what is the relation between the ENERGY-OBJECT-MIB MIB module tables, the associated UML diagram given in Figure 1 and the text other subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).. Please make this relation clear.

Comment_2: The same holds for the powerAttributeMIB MIB module tables, UML diagram given in Figure 2 and subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).

Comment_3: The description of the powerAttributeMIB MIB module tables on page 8 is too short. A similar description as the one described for the ENERGY-OBJECT-MIB MIB module tables in page 6 could be also provided,

Comment_4: Some parts of the UML diagram given in Figure 2 as representing the relations in the powerAttributeMIB are (probabl)  part of the ENERGY-OBJECT-MIB. These are the Energy ParametersTable and EnergyTable.

Comment_5: not all entries (MIB objects) depicted in the ENERGY-OBJECT-MIB MIB module tables are shown in the UML diagram depicted in Fgure 1.Please elaborate.

Comment_6: the same holds for powerAttributeMIB MIB module tables  and the UML diagram depicted in Figure 2.

Comment_7: Maybe the title of Section 5.1 should be: Enetgy Object Identity, instead of Energy Object Information?

Comment_8: The description of the vertical axis used in Figure 3 is not clear to me. Are both horizontal axis and vertical axis representing time. Regarding the vertical axis you might want to say that the vertical axis represents the amount of measured power ?

Comment_9: The description of Figure 4 is not clear to me. You might include at the right sde of the figure and for each window the term S+L, so (S1+L, S2+L, S3+L and S4+L). You can then explain that the value of the EoEnergyConsumed is obtained at these time intervals (Sx+L)..

Comment_10: Section 6 is very important and its importance should be emphasized more clearly in the Introduction.

Comment_11: In Section 6 the term EMAN-MON-MIB is used for the first time. I considered that it referes to this document. Please emphasize that in the text.

Comment_12: Section 8 provides an example for the implementation of the Energy Object, including the Energy Object relationships. Is it possible to provide an example of the IANAEnergyRelationship (in particular regaring aggregation) defined in [ENERGY-AWARE-MIB].

Comment_13: Are the MIB objects defined in this draft complying with the mechanisms defined by SMIv2 [RFC2578, RFC2579, RFC2580? If yes, please emphasize this in the document!

Best regards,
Georgios Karagiannis

________________________________
Van: eman [[email-masked]<mailto:[email-masked]>] namens Thomas Nadeau [[email-masked]<mailto:[email-masked]>]
Verzonden: maandag 30 december 2013 20:52
To: Juergen Quittek
Cc: eman mailing list
Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

        The note said 8AM EDT. *)

        Anyways, send over your comments ASAP.

        --Tom

On Dec 30, 2013:1:46 PM, at 1:46 PM, Juergen Quittek <[email-masked]<mailto:[email-masked]>> wrote:

> Hi Tom,
> I missed the fact that the deadline is already in the morning of today. I thought I had the full day today for sending them. There are still some comments that I planned to send this evening. I will send them asap and hope they will be OK even if a few hours late.
> Thanks,
>    Juergen
>
>> Sent: Montag, 30. Dezember 2013 14:44
>> To: eman mailing list
>>       WG,
>>       This concludes the WG LC on the MIBs. We have received just one set
>> of comments from the WG and one set of comments regarding the OID
>> numbering. Would the document editors please address these and republish
>> the drafts ASAP so that we can proceed with progressing the drafts?
>>
>>       Cheers and Happy Holidays,
>>
>>       Tom
>>
>>
>>>
>>> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 22 Jan 2014 09:54:17 +0000

Hi Mouli,

Thanks for your answers!

Best regards,
Georgios

From: Mouli Chandramouli (moulchan) [mailto:[email-masked]]
Sent: dinsdag 21 januari 2014 13:41
To: Karagiannis, G. (EWI); [email-masked]
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Hi  Georgios,

Replies inline.

Thanks
Mouli

Hi all,

Here are my comments!

Comment_2: In section 5.2, page 20 is mentioned: "The Energy Object can be classified as consuming power or supplying power to other devices or that Energy Object can perform both of those functions, ..". However, in the formal MIB definition on page 20, eoPowerCategory can get the values: consumer (0), producer(1), meter(2), distributor(3) or store(4). From what I can see no value is provided for the situation that the energy object can perform both functions consumer and producer.

Best regards,
Georgios Karagiannis

        --Tom

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 27 Jan 2014 16:14:46 +0000

Hi Benoit,

Thank you for your replies on all technical comments.

I have two issues with the replies. One is stated in the email 
below, the other one will come in a separate email.

Energy Management Domain
======================

The eman framework states: "An Energy Object should 
be a member of a single Energy Management Domain".

Now and draft-ietf-eman-energy-aware-mib sharpens this to
"Each Energy Object MUST belong to a single Energy 
Management Domain".

This change from "should" to "MUST" is inappropriate.

The situation is that Cisco's EnergyWise uses a single domain 
while some other products use multiple domains. We went 
on with the recommendation for a single domain in the 
framework because of the positive experience with 
EnergyWise and no reported complaints on this from 
EnergyWise customers.

But no technical argument was ever given for restricting a
device to be member of a single domain only. In contrary, 
I reported from applications of the multiple domain approach 
without anyone challenging this technically.

The compromise in the framework was to recommend the 
EnergyWise approach but not to completely exclude competing 
approaches.

With a change from "should" to "must" you changed a lot in 
this game. I do not see any _technical_ reason for this step.

In my comments I suggested a way that only needs a small 
modification of one object's DESCRIPTION clause to be open
for other implementations using multiple domains. My proposal
still kept the recommendation for using a single domain only
(even in the absence of a technical reason for this) but showed
how to act if you have a strong need for multiple ones.

I propose to stay with the compromise achieved in the framework
document and leave the door open for implementations that
have (as RFC 2119 says) "valid reasons in particular circumstances"
to choose a multi-domain approach.

Best regards,
    Juergen

> From: Benoit Claise [mailto:[email-masked]]
> Sent: Freitag, 17. Januar 2014 17:20
> To: Juergen Quittek; eman mailing list
> 	Below please find my comments on draft-ietf-eman-energy-aware-
> mib-13 titled "Energy Object Context MIB". I will send comments on draft-ietf-
> eman-energy-monitoring-mib-08 in a separate message.
> 
> 	==================
> 	Technical comments:
> 	==================
> 
> 	1) Section 5.1, 3rd paragraph: Since you are already very precise
> about this MUST, I would add that the name MUST NOT have length zero.
> 
> Not sure this is correct. RFC 6933 allows a zero-length string. See the second
> paragraph below.
> 
> This sentence actually means that if an assigned name is used, it must be a
> printable one.
> However, I wonder if this that sentence is needed at all, because we overrule
> the entPhysicalName definition from the ENTITY-V4 RFC.
> 
>                  information, preferably in human-readable form.
> 
> 	2) Section 5.1, one but last 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." This is
> more strict than in the framework where we say an EO "should" not belong to
> more than one domain. However, as we have discussed several times, there
> are management systems that use more than one domain (different to
> "should" clause that we have in the framework, but we should not fully
> exclude other solutions with a "must" clause. See also comment 7).
> 
> use a vector for the keywords to allow for further defining context you
> describe. We proposed scalar for the PRIMARY category and the PRIMARY
> role.
> 
> 
> And, most importantly, http://www.ietf.org/mail-
> archive/web/eman/current/msg02037.html, which is the outcome of the
> authors call, supervised by Nevil:
> 
> 
> 	*** Scalar vs Vector
> 	       Category  - overloaded if vectore { cons, prod, meter, distributor,
> store }
> 	       Location? (new) - clearly not vector but semantic like rfc4776
> better geo-priv
> 	Both paragraphs need more explanation and you need to make them
> consistent with the text in the MIB modules. For LLDP you say "If the LLDP MIB
> is implemented". Why don't you have a similar statement for the PoE MIB?
> You talk about "the" Energy Object SNMP agent. However, EOs may not have
> SNMP agents, for example, if they are just a power interface. And it is not
> specified which of the potentially numerous instances of lldpLocPortNum
> objects of a device should be reported.
> 
> 	B) Please note that the choice is not only with the manufacturer. Even
> if the manufacturer builds in SNMP, the operator may choose to disable it ;-)
> 
> 	Why is it relevant for the specification of this object, if that a certain
> MIB module "should" be implemented on that device? Does it make any
> different for the DESCRIPTION of this object whether or not this MIB module is
> 	Please insert as second sentence: "If the energy object has been
> assigned to multiple domains, then they are represented in this object as
> comma-separated list.", see comment 2).
> 
> See point 2.
> 
> 
> 
> 	Some devices match more than one category, for example a UPS is a
> store and a distributor at the same time, and to be precise, also a consumer. A
> PoE Switch is a consumer and a distributor, some devices switch between
> consumer and producer, etc. We can support all of this if we change the
> syntax from INTEGER to BITS.
> 
> See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why
> not to do this.
> 
> 
> 
> 	There is a contradiction between having this object with MAX-ACCESS
> read-write and stating " This object specifies a manufacturer defined string". If
> the manufacturer defines the string, there is no need to write it. I suggest
> allowing the operator to set the value of this document.
> 
> 	I recommend adding a sentence to the DESCRIPTION clause, that
> preferable the value of an entPhysicalUUID from the Entity MIB should be
> used for values of this object.
> 
> ok.
> 
> 
> 
> 
> 	The dependence of compliance with entity4CRCompliance is stated in
> the GROUP DESCRIPTION clauses. In our case, this is not the right place. There
> is a dependency on entity4CRCompliance  independent of which group is
> 	We state in other places that implementation of the Entity MIB
> compliant with entity4CRCompliance is a must. But in the conformance section
> of the ENERGY-OBJECT-CONTEXT-MIB the dependency on
> entity4CRCompliance is stated as "should". This need to be changed to a
> "must" or "required."
> 
> Good catch.
> 
> 
> 
> 
> 	For interoperability, the description need to be clear. As this TC is
> stated, there are two points unclear to me:
> 	If the TC is used, how do I know which object is A and which is B? Is it
> that the DESCRIPTION clauses of objects of this type must refer to object A and
> object B?
> 
> OLD:
> 
> Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation
> relationship as a summation. I guess you want some more text in this section
> 5.4?
> 
> 
> 
> 
> 	=================
> 	Editorial comments:
> 	=================
> 
> 	"relationships between reporting devices, remote devices, and
> monitoring devices.": The enumeration of "reporting devices", "monitoring
> devices", and "remote devices" is inappropriate because it does not reflect
> the list of relationships discussed by the draft: poweredBy, meteredBy,
> aggregatedBy.
> 
> 	"A second MIB module required by the [EMAN-FMWK]": There is no
> MIB module required by the EMAN framework. It seems you wanted to say: "A
> 	This section is completely redundant. It mainly repeats sentences of
> section 1.1. Remove this section and merge sentences you want to keep into
> section 1.1
> 
> 	The sentence is not grammatically correct, please fix. Also semantic
> correction seems to be needed. You don't mention "identification" as focus of
> the first table.
> 
> 	In Figure 1 you have three groups: "Context", "Identification",
> "Relationships", where "Identifications" has three subgroups. The sentence
> below the figure emphasizes this grouping. However, the following
> subsections 5.1-5.4 are grouped differently. 5.1 is titled "Identification" but
> covers only a third of the objects under "Identification" in Figure 1. Section
> 5.2 is consistently with Figure 1 covering context information. Section 5.3
> covers PoE and LLDP identification. Sections 5.4 is called "Relationships" but
> covers not just the objects under "Relationships" in Figure 1, but also objects
> from under "Identification" in Figure 1. Here is a clean-up needed. Please split
> the last sentence from section 5.4. It firs much better in section 5.3.
> 
> 	Please note that subsection 5.5 is not another group of MIB objects
> but refers to objects in subsection 5.1. The sentence above the enumeration
> implies that each numbered item would be a group of objects.
> 
> 	The comment "Note that object eoRelationIndex is not included since
> it is not-accessible" is not really needed. Almost every Conformance section
> has such objects and usually this comment is omitted.
> 
> 	Cheers,
> 	    Juergen
> 
> 
>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 27 Jan 2014 11:48:36 -0500

EMAN WG,

	Nevil, Benoit and I have discussed this issue at length. Given the 11:45th hour on this document, we independently went 
through the history of the document as well as the various LC comments to see if there was a simple and quick 
solution to the point Juergen raised during the LC. It seems that the language of MUST or SHOULD makes a 
big difference at the MIB level and/or makes the MIBs not-conforming with the Framework depending on what we decide to do
here.  There does seem to be some history behind this one, whereby the document was changed to a SHOULD from a MUST. 

	Just a little background on the matter:

	The current framework contains a SHOULD in section 6.3.6 that is kind of contradicted by the "recommended ... 1:1" text above it. 

	One way or another, these need to be made consistent and painfully obvious:

 6.3.6. Context: Domain 

     
    Claise et al.          Expires October 30 2015      [Page 17] 

    Internet-Draft             EMAN Framework        January 2014 
        
       The Energy Object (Class) contains a string attribute to 
       indicate membership in an Energy Management Domain. An 
       Energy Management Domain can be any collection of Energy 
       Objects in a deployment, but it is recommended to map 1:1 
       with a metered or sub-metered portion of the site.  
        
       In building management, a meter refers to the meter 
       provided by the utility used for billing and measuring 
       power to an entire building or unit within a building.  A 
       sub-meter refers to a customer- or user-installed meter 
       that is not used by the utility to bill but is instead used 
       to get measurements from sub portions of a building. 

	In order conform to the framework, The Energy-Mon MIB has Section 6, DESCRIPTION clause of object eoDomainName:

	The issue here is that comma-separated string is a pain as the NMS has to check every string for comma. But the alternatives are far more messy.

	Based on the above, this point we believe there is one option that will sort this situation out:

	Change the "should" to a "must" as well as the "recommended" to a "must" in the framework. That makes the framework itself consistent 
without any doubt as to there being a single domain per object. This also fixes the issue above with the MIB. 

	--Tom

> -------- Original Message --------
> Date:	Fri, 17 Jan 2014 17:20:13 +0100
> From:	Benoit Claise <[email-masked]>
> To:	Juergen Quittek <[email-masked]>, eman mailing list <[email-masked]>
> 
> Hi Juergen,
> 
> Not sure this is correct. RFC 6933 allows a zero-length string. See the second paragraph below.
> This sentence actually means that if an assigned name is used, it must be a printable one.
> However, I wonder if this that sentence is needed at all, because we overrule the entPhysicalName definition from the ENTITY-V4 RFC.
> JP : We've discussed this at length and the approach we chose was to use a vector for the keywords to allow for further defining context you describe. We proposed scalar for the PRIMARY category and the PRIMARY role.
> 
> And, most importantly, http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil:
> *** Scalar vs Vector
>        Category  - overloaded if vectore { cons, prod, meter, distributor, store }
>        Location? (new) - clearly not vector but semantic like rfc4776 better geo-priv
> See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why not to do this.
>> 
> Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation relationship as a summation. I guess you want some more text in this section 5.4?
>> =================
>> Editorial comments:
>> =================
> <Attached Message Part.txt>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 27 Jan 2014 13:09:36 -0500

Apologies, but I should have said that Benoit's involvement here was only as a contributor.

	--tom

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 27 Jan 2014 13:26:23 -0500

Juergen,

	Apologies but our emails crossed inflight it seems. 

> below, the other one will come in a separate email.

	As I pointed out in my email just now, there are a number of
implications to the proposed change as well as the currently 
misaligned state of things.  After the chairs reviewed the situation
in detail including the history of the compromise, we felt that 
the consensus for the approach was in fact to go with a single 
domain. The reasoning was simple: the compromise that was made quite a
long time ago to converge on the single domain approach. It seems that 
the text in the Framework was not aligned with this decision. 
This is my in my previous email the chairs asked that The Framework 
document be changed to use MUST (and aligned the other sentence with 
the 1:1 comment", as well as align the text in the MIB.

	Tom/Nevil

---

From: Nevil Brownlee <[email-masked]>
Date: Tue, 28 Jan 2014 09:45:53 +1300

Hi EMAN WG:

A brief note to make this point clear ...

 From the WGLC comments on the MIBs, it's become clear that allowing
MIB objects to belong to more than one Energy Management Domain will
make it complicated to implement the MIBs than we'd like.  Tom
summarised two possible solutions to this for me:

 > 1) Change the "should" to a "must" as well as the "recommended"
 >    to a "must" in the framework. That makes the framework itself
 >    consistent without any doubt as to there being a single domain per
 >    object.
 >
 > 2) Leave the framework as is, but require the MIB to handle objects
 >    belonging to multiple domains.   As was mentioned, it currently is
 >    implemented as a free-form string. The text above regarding making
 >    it comma-separated is difficult for implementations, but is not
 >    the end of the world.  Things could also be enhanced if we added a
 >    variable called NumDomainsype and would indicate the number of
 >    domains present, and hence the number of commas to search for. Of
 >    course, then there are the corner cases to check for etc ...
 >    The best way to implement this sort of thing is via a sparse
 >    table, but that is water under the bridge now I suppose.

Of these, I consider that (1) is much the simplest.  Therefore, I'd
like - as WG co-chair - to see the Framework changed so that using a
single energy Management Domain is definitely a MUST.

I realise that it's very late to make such a change, but I feel that
it's overall better for EMAN.  Does anyone on the EMAN list have any
strong objection to this change?  All feedback is - as always - welcome.

Also, please note that although Benoit has provided helpful commentary
on this recently, he did so simply as a document author.  My propsal
above (Framework change to MUST) is this is a WG Chair decision.

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Brad Schoening <[email-masked]>
Date: Tue, 28 Jan 2014 05:52:50 +0000

I've updated the doc to address Juergen's 2nd point.  But, is there
consensus on MUST vs SHOULD for Entity MIB support?

On 12/30/13 2:33 PM, "Juergen Quittek" <[email-masked]> wrote:

>Dear all,
>
>Here are my last two comments for this WGLC. Both concerns the
>conformance section of the ENERGY-OBJECT-MIB module in
>draft-ietf-eman-energy-monitoring-mib-08:
>
>1. I may have missed a point here: Why is the Entity MIB not mandatory
>anymore to implement? It is just two additional objects, since
>entPhysicalIndex from this MIB is needed anyway. Particularly, we
>considered the UUID provided by this MIB essential for our framework.
>
>2. Why is the module compliance dependency on the Entity MIB repeated in
>the DESCRIPTION clauses of all optional groups within a MODULE-COMPLIANCE
>declaration? I think It is fully sufficient to have it stated in the top
>DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make any
>sense to repeat it for optional groups?
>
>Cheers,
>    Juergen
>
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 28 Jan 2014 10:03:35 -0500

Hi Brad/EMAN WG,

	As both Nevil and I noted yesterday, we both consider that there 
is sufficient consensus to have the Framework changed so that using a single 
Energy Management Domain is written as a MUST in the documents. As chairs we 
are directing the editors of the draft to please make this change so that the 
MIBs and the Framework will be aligned. 

	We both I understand that it is very, very late in the game to 
make this change, but this needs to happen to keep the ball rolling forward 
for EMAN and all of the existing implementations.  Under the circumstances, 
we also understand that this might have taken people by surprise, and thus 
while we do not want to re-open the debate/discussion that happened around 
this issue a while back now, we would still like to ask the WG if anyone on 
the EMAN list has a strong objection to this change or how it should be made 
to the drafts. Please chime in ASAP. If we do not hear anything by Friday, 
January 31, 2014 at 8AM EDT, we will proceed forward as directed.

	--Tom

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 29 Jan 2014 23:41:39 +0000

Hi Tom,

You are right. This is really comes as a surprise. 
I have an objection. Please see my reasons below.

0. (just formal) You ask for changing the framework draft in an email that has two drafts in the subject line, but not the framework draft. A clearer indication of this email would have been particularly recommendable, since you told us at the last meeting that you are not willing to accept further change requests to this draft.

1. Having a device limited to a single domain membership is a limitation/feature of Cisco's EnergyWise for which in all the long discussions we had in past year never any technical reason was given (although it was asked for multiple times). In the contrary, I gave use cases where it is REQUIRED to have two or more domains. An obvious example is a highly reliable server that has dual power supply. Its two power supply lines SHOULD be in different domains in order to be better protected from local power supply failures. This server should be given means to report via the MIB that it is member of two domains.

2. The compromise we had was RECOMMENDING to use the same limitation as EnergyWise has it even though we know other systems do not have that limitations and even though technical reason exists rather against the limitation than for it. The proposed change to MUST makes all other (potentially superior) approaches violating the standard. Why shall we do so without ANY technical reason? What would be the reason for such a decision?

3. The suggestion I made does NOT require any modifications of existing SNMP agents that implement one of the recent versions of the MIB modules in draft-ietf-eman-energy-aware-mib. It also does not affect any code transmitting information using the EMAN information model as specified in the framework. The domain information is still kept in a single string. It only gives a little bit of freedom to how this string can be interpreted when processing it, particularly when writing it to a management data base supporting either single or multiple domains per device.

4. To make the story even more surprising, the concept of a "domain" is not defined in a very interoperable way. The framework does not give the concept of a domain any more semantics than 
    "An Energy Management Domain can be any collection of Energy Objects in a deployment." 
How to structure domains is completely left to the operator. Why are we on one hand so open with the semantics of a "domain" and on the other hand so strict when it comes to the number of domain memberships an energy object may have?

5. You say you request the change to keep the ball rolling. But you propose the opposite: to make a step back to the already closed framework draft and open it again. The way to keep the ball rolling would be to just apply changes to the still open documents we are currently discussing.

    Juergen

> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Dienstag, 28. Januar 2014 16:04
> To: Brad Schoening
> Cc: Juergen Quittek; eman mailing list
> 	As both Nevil and I noted yesterday, we both consider that there is
> sufficient consensus to have the Framework changed so that using a single
> Energy Management Domain is written as a MUST in the documents. As chairs
> we are directing the editors of the draft to please make this change so that
> the MIBs and the Framework will be aligned.
> 
> 	We both I understand that it is very, very late in the game to make this
> change, but this needs to happen to keep the ball rolling forward for EMAN
> and all of the existing implementations.  Under the circumstances, we also
> understand that this might have taken people by surprise, and thus while we
> do not want to re-open the debate/discussion that happened around this
> issue a while back now, we would still like to ask the WG if anyone on the
> EMAN list has a strong objection to this change or how it should be made to
> the drafts. Please chime in ASAP. If we do not hear anything by Friday, January
> 31, 2014 at 8AM EDT, we will proceed forward as directed.
> 
> 	--Tom
> 
> 
> >> 1. I may have missed a point here: Why is the Entity MIB not
> >> mandatory anymore to implement? It is just two additional objects,
> >> since entPhysicalIndex from this MIB is needed anyway. Particularly,
> >> we considered the UUID provided by this MIB essential for our framework.
> >>
> >> 2. Why is the module compliance dependency on the Entity MIB repeated
> >> in the DESCRIPTION clauses of all optional groups within a
> >> MODULE-COMPLIANCE declaration? I think It is fully sufficient to have
> >> it stated in the top DESCRIPTION clause of the MODULE-COMPLIANCE
> >> declaration. Does it make any sense to repeat it for optional groups?
> >>
> >> Cheers,
> >>   Juergen
> >>
> >>

---

From: <[email-masked]>
Date: Thu, 30 Jan 2014 06:31:20 +0000

Hi Tom,

I agree with the objections mentioned by Juergen in the below email, and in particular with the recommendation:

"The way to keep the ball rolling would be to just apply changes to the still open documents we are currently discussing."

Best regards,

Georgios

________________________________
Van: eman [[email-masked]] namens Juergen Quittek [[email-masked]]
Verzonden: donderdag 30 januari 2014 0:41
To: Thomas Nadeau; eman mailing list
Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Hi Tom,

    Juergen

---

From: joel jaeggli <[email-masked]>
Date: Thu, 30 Jan 2014 08:09:30 -0800

On 1/29/14, 3:41 PM, Juergen Quittek wrote:
> Hi Tom,
> 
> You are right. This is really comes as a surprise. I have an
> objection. Please see my reasons below.
> 
> 0. (just formal) You ask for changing the framework draft in an email
> that has two drafts in the subject line, but not the framework draft.
> A clearer indication of this email would have been particularly
> recommendable, since you told us at the last meeting that you are not
> willing to accept further change requests to this draft.

Just as a quick observation.

If we have a problem with the document then we should fix it. WG chairs
have pretty wide latitude to determine when something is done with
respect to the next stages,

It is unlikely all things consider that it will emerge for IETF lc and
IESG review without further editoral change/ so if we have problems that
we anticipate having to address there, then perhaps we should do that now.

> 1. Having a device limited to a single domain membership is a
> limitation/feature of Cisco's EnergyWise for which in all the long
> discussions we had in past year never any technical reason was given
> (although it was asked for multiple times). In the contrary, I gave
> use cases where it is REQUIRED to have two or more domains. An
> obvious example is a highly reliable server that has dual power
> supply. Its two power supply lines SHOULD be in different domains in
> order to be better protected from local power supply failures. This
> server should be given means to report via the MIB that it is member
> of two domains.

It seems like the question is should the MUST reflect the current status
of the mibs or not?

if that's the question, then, is there some reason we should be tolerant
of a discrepancy between the two? Latitude for implementers is fine and
dandy (and may well be necessary) but if you can't express the element
you've modeled in the monitoring that seems like an issue that needs to
be reconciled either in the framework or in the mib.

> 2. The compromise we had was RECOMMENDING to use the same limitation
> as EnergyWise has it even though we know other systems do not have
> that limitations and even though technical reason exists rather
> against the limitation than for it. The proposed change to MUST makes
> all other (potentially superior) approaches violating the standard.
> Why shall we do so without ANY technical reason? What would be the
> reason for such a decision?
> 
> 3. The suggestion I made does NOT require any modifications of
> existing SNMP agents that implement one of the recent versions of the
> MIB modules in draft-ietf-eman-energy-aware-mib. It also does not
> affect any code transmitting information using the EMAN information
> model as specified in the framework. The domain information is still
> kept in a single string. It only gives a little bit of freedom to how
> this string can be interpreted when processing it, particularly when
> writing it to a management data base supporting either single or
> multiple domains per device.
> 
> 4. To make the story even more surprising, the concept of a "domain"
> is not defined in a very interoperable way. The framework does not
> give the concept of a domain any more semantics than "An Energy
> Management Domain can be any collection of Energy Objects in a
> deployment." How to structure domains is completely left to the
> operator. Why are we on one hand so open with the semantics of a
> "domain" and on the other hand so strict when it comes to the number
> of domain memberships an energy object may have?
> 
> 5. You say you request the change to keep the ball rolling. But you
> propose the opposite: to make a step back to the already closed
> framework draft and open it again. The way to keep the ball rolling
> would be to just apply changes to the still open documents we are
> currently discussing.
> 
> Juergen
> 
> 
>> -----Original Message----- From: Thomas Nadeau
>> [mailto:[email-masked]] Sent: Dienstag, 28. Januar 2014
>> 16:04 To: Brad Schoening Cc: Juergen Quittek; eman mailing list 
>> Subject: Re: [eman] WG Last Call for
>> draft-ietf-eman-energy-monitoring-mib- 08 and
>> draft-ietf-eman-energy-aware-mib-13
>> 
>> 
>> Hi Brad/EMAN WG,
>> 
>> is sufficient consensus to have the Framework changed so that using
>> a single Energy Management Domain is written as a MUST in the
>> documents. As chairs we are directing the editors of the draft to
>> please make this change so that the MIBs and the Framework will be
>> aligned.
>> 
>> We both I understand that it is very, very late in the game to make
>> this change, but this needs to happen to keep the ball rolling
>> forward for EMAN and all of the existing implementations.  Under
>> the circumstances, we also understand that this might have taken
>> people by surprise, and thus while we do not want to re-open the
>> debate/discussion that happened around this issue a while back now,
>> we would still like to ask the WG if anyone on the EMAN list has a
>> strong objection to this change or how it should be made to the
>> drafts. Please chime in ASAP. If we do not hear anything by Friday,
>>> I've updated the doc to address Juergen's 2nd point.  But, is
>>> there consensus on MUST vs SHOULD for Entity MIB support?
>>> 
>>> 
>>> 
>>>> mandatory anymore to implement? It is just two additional
>>>> objects, since entPhysicalIndex from this MIB is needed anyway.
>>>> Particularly, we considered the UUID provided by this MIB
>>>> essential for our framework.
>>>> 
>>>> 2. Why is the module compliance dependency on the Entity MIB
>>>> repeated in the DESCRIPTION clauses of all optional groups
>>>> within a MODULE-COMPLIANCE declaration? I think It is fully
>>>> sufficient to have it stated in the top DESCRIPTION clause of
>>>> the MODULE-COMPLIANCE declaration. Does it make any sense to
>>>> repeat it for optional groups?
>>>> 
>>>> Cheers, Juergen
>>>> 
>>>> 
>>>>> -----Original Message----- From: eman
>>>>> [mailto:[email-masked]] On Behalf Of Thomas
>> Nadeau
>>>>> Sent: Montag, 16. Dezember 2013 16:56 To: eman mailing list 
>>>>> Subject: [eman] WG Last Call for 
>>>>> draft-ietf-eman-energy-monitoring-mib-08 and
>>>>> draft-ietf-eman-energy-aware-mib-13
>>>>> 
>>>>> 
>>>>> completing its WG LC the chairs would like to initiate a WG
>>>>> LC on draft-ietf- eman-energy-monitoring-mib-08 and
>>>>> draft-ietf-eman-energy-aware-mib-
>> 13.
>>>> _______________________________________________ eman mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/eman
>>> 
>>> _______________________________________________ eman mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/eman
>>> 
> 
> _______________________________________________ eman mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/eman
>

---

From: Brad Schoening <[email-masked]>
Date: Thu, 30 Jan 2014 16:59:09 +0000

Hi Thomas,

Just wanted to clarify that I was inquiring about a separate issue from
this one about single or multiple domains.

That issue had to do with Entity-MIB support, and after further review,
I've updated the MIB on that issue along the lines Juergen recommended.

Regards,

Brad

On 1/28/14 7:03 AM, "Thomas Nadeau" <[email-masked]> wrote:

>we 
>>>in
>>>> draft-ietf-eman-energy-monitoring-mib-08

---

From: Brad Schoening <[email-masked]>
Date: Thu, 30 Jan 2014 17:42:06 +0000

Juergen,

In your dual power supply example, I would think of these as three
domains: supplyA, supplyB and supplyAB.  The new domain supplyAB is a
high-reliabliy domain.  You don't mention what the power policy of this
new combined domain is, but there could be several choices for supplyAB.

Consider a more complicated example, you have a chassis with three power
supply modules.  There are at least three different policies that could be
applied:

- Power module redundancy - total power allowed is one less than the
number of supply modules
  E.g., total power is 2 x.

- Power module redundancy with throttling - total power allowed is equal
to available power, but
  requires consumers to throttle down if one module fails.  E.g., total
power is between 2x and 3x.

- Basic power w/o redundancy - total power allowed is equal to all
available power with no redundancy.  E.g., total power is 3x.

Combining power domains likely always invokes a policy and thus in the
eman model, creates a new domain.

This approach is compatible with the chairs suggestion of MUST.

Regards,

Brad

On 1/29/14 3:41 PM, "Juergen Quittek" <[email-masked]> wrote:

>(although it was asked for multiple times). In the contrary, I gave use
>cases where it is REQUIRED to have two or more domains. An obvious
>example is a highly reliable server that has dual power supply. Its two
>power supply lines SHOULD be in different domains in order to be better
>protected from local power supply failures. This server should be given
>means to report via the MIB that it is member of two domains.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 30 Jan 2014 13:55:32 -0500

Hi Brad,

> I've updated the MIB on that issue along the lines Juergen recommended.

	OK cool. Apologies, but I thought you were asking about the other issue. *)

	--Tom

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 30 Jan 2014 19:40:40 +0000

I agree with the chairs and our approach that the device/chassis is a scalar domain not a vector. As agreed in the framework model.

The complexity of power supplies (stack power for example) is handled by grouping (keywords) not the management domain( i.e. community). MUST is the preferred approach in practice.

Our implementations and experience have found that no site ever used the domain for this purpose but used groupings as Brad expressed below.

Also the information model has been expressed as scalar not a vector for this field for some time and we have feedback and consensus on running code that this is preferable.

A change to SHOULD would mean we'd have to add attributes for size of field /table to do a proper vector. That would mean soliciting feedback from implementors that already are expecting / using this as a scalar. most are not paying attention since wglc.

Change the framework error not the modelling at this point please.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes)

---

From: Ted Ghose <[email-masked]>
Date: Thu, 30 Jan 2014 19:43:23 +0000

+1
-Ted-
Sent from my iPhone

> On Jan 30, 2014, at 11:40 AM, "John Parello (jparello)" <[email-masked]> wrote:
>

---

From: Bruce Nordman <[email-masked]>
Date: Thu, 30 Jan 2014 13:31:11 -0800

For the Domain issue, I have always believed that the Framework draft
did not define the concept well.  Since it is ambiguous in the Framework,
it is not surprising that we are running into problems with it in later
stages (the MIBs for example).

The current Framework states (6.3.6):

   An Energy Management Domain can be any collection of Energy
   Objects in a deployment, but it is recommended to map 1:1
   with a metered or sub-metered portion of the site.

If one uses domain in the recommended fashion, then a device that receives
power from two sources (each sub-metered) is definitely in two different
domains.
If one uses it differently, as is permitted, then many reasonable
and useful usages require more than one domain.

Another way to think about this is that it was a flawed idea in
the first place that a device is in a domain at all.  It is the
power interface (or interfaces, for devices which receive supply
from more than one) that is in the domain, not the device itself.
An interface is more clearly in one domain.  Different types of
entities (devices, components, power interfaces) have different
types of data available, so having domain only in the PI is quite
reasonable.

Thus, the correct answer to me for domain for a device is either
zero or multiple.  To recommend one as a compromise seeks OK.
For a PI, only a single domain is needed.

I second Juergen's line of reasoning that it is quite unnecessary
and not justified to make the framework change to single at this time.

Thanks,

--Bruce

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov <http://nordman.lbl.gov>*
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Brad Schoening <[email-masked]>
Date: Thu, 30 Jan 2014 22:07:54 +0000

"If one uses domain in the recommended fashion, then a device that receives
power from two sources (each sub-metered) is definitely in two different
domains."

Or a new domain, which combines the two and has its own power policy.  In which case, a single domain suits our model quite well.

Regards,

Brad

From: Bruce Nordman <[email-masked]<mailto:[email-masked]>>
Date: Thu, 30 Jan 2014 13:31:11 -0800
To: eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Thanks,

--Bruce

--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov<http://nordman.lbl.gov>
[email-masked]<mailto:[email-masked]>
510-486-7089
m: 510-501-7943
_______________________________________________ eman mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/eman

---

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 31 Jan 2014 05:48:43 +0000

Hi JQ,

Sorry I'm not seeing how point 1 is not covered. The domain attribute is on an EnergyObject.

Modeled as in case Case 3 of section 8.1
http://tools.ietf.org/html/draft-ietf-eman-framework-14#section-8.1

DeviceX.domain=foo
DeviceX.PI1.domain=bar
DevixeX.PI2.domain=bin

Are you asking for a single power inlet to be required in two domains?

Lets fix the typo in the framework and move on please.
Jp

Sent from my iPad

On Jan 30, 2014, at 12:42 AM, "Juergen Quittek" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom,

   Juergen

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: Dienstag, 28. Januar 2014 16:04
To: Brad Schoening
Cc: Juergen Quittek; eman mailing list
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-

   Hi Brad/EMAN WG,

   --Tom

On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening
<[email-masked]<mailto:[email-masked]>> wrote:

On 12/30/13 2:33 PM, "Juergen Quittek" <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Cheers,
 Juergen

-----Original Message-----
From: eman [mailto:[email-masked]] On Behalf Of Thomas
Nadeau

   As agreed at the last WG meeting, with the EMAN Framework
completing its WG LC the chairs would like to initiate a WG LC on
draft-ietf-
eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-
13.
The WG LC will end on Dec 30 at 8AM EDT.

   Thank you,

   Nevil and Tom

---

From: Thomas Dietz <[email-masked]>
Date: Fri, 31 Jan 2014 08:15:36 +0000

Dear Brad, all,

first of all I second Jürgen’s view that we should not artificially limit
ourselves if there is no technical reason.

And what the discussion below shows is exactly the reason for that. The
definition of the domain leaves some room for interpretation. Thus, IMHO it
should be allowed to have an implementation of a domain that allows that
objects are part of more than one domain. You could define the domain as a
sort of “geographical domain” and have a building that get controlled by the
owner and some rental units that are controlled by the tenant. This would
imply that the same object are part of two different domain. And this
example would match in my opinion the definition of domain in the framework
document.

Best Regards,

Thomas

-- 

Thomas Dietz

NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014

Registered Office: Athene, Odyssey Business Park, West End  Road, London,
HA4 6QE, GB

From: eman [mailto:[email-masked]] On Behalf Of Brad Schoening
Sent: Thursday, January 30, 2014 11:08 PM
To: Bruce Nordman; eman mailing list
Subject: Re: [eman] WG Last Call for
draft-ietf-eman-energy-monitoring-mib-08 and
draft-ietf-eman-energy-aware-mib-13

domains."

Or a new domain, which combines the two and has its own power policy.  In
which case, a single domain suits our model quite well.

Regards,

Brad

From: Bruce Nordman <[email-masked] <mailto:[email-masked]> >
Date: Thu, 30 Jan 2014 13:31:11 -0800
To: eman mailing list <[email-masked] <mailto:[email-masked]> >
Subject: Re: [eman] WG Last Call for
draft-ietf-eman-energy-monitoring-mib-08 and
draft-ietf-eman-energy-aware-mib-13

Thanks,

--Bruce

-- 

Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov <http://nordman.lbl.gov> 
[email-masked] <mailto:[email-masked]> 
510-486-7089
m: 510-501-7943

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

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 31 Jan 2014 08:47:55 +0000

I agree with the chairs and each energy object must belong to a single domain.

The MIB modules that have been presented and reviewed many times over,  have also stressed the importance of 1-1 mapping between  an Energy Object and a domain.

Keywords can be used as tags for other groupings of energy objects.

Thanks
Mouli

Jp

Sent from my iPad

On Jan 30, 2014, at 9:42 AM, "Brad Schoening" <[email-masked]<mailto:[email-masked]>> wrote:

Juergen,
On 1/29/14 3:41 PM, "Juergen Quittek" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Rolf Winter <[email-masked]>
Date: Fri, 31 Jan 2014 10:03:22 +0000

I agree here. I think the changes are a) quite late and b) not in line with the textual description of a domain. Have we gotten the some of the concepts all wrong/ill defined (something that was voiced before on the mailing list)? I am also puzzled about process here. I think in the last meeting I was told that no further changes were allowed (I believe). Now we make further changes. 

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

> From: eman [mailto:[email-masked]] On Behalf Of Bruce Nordman
> Sent: Donnerstag, 30. Januar 2014 22:31
> To: eman mailing list
> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-
> mib-08 and draft-ietf-eman-energy-aware-mib-13
> 
> did not define the concept well.  Since it is ambiguous in the
> Framework, it is not surprising that we are running into problems with
> it in later stages (the MIBs for example).
> 
> If one uses domain in the recommended fashion, then a device that
> receives power from two sources (each sub-metered) is definitely in two
> different domains.
> If one uses it differently, as is permitted, then many reasonable and
> useful usages require more than one domain.
> 
> Another way to think about this is that it was a flawed idea in the
> first place that a device is in a domain at all.  It is the power
> interface (or interfaces, for devices which receive supply from more
> than one) that is in the domain, not the device itself.
> entities (devices, components, power interfaces) have different types
> of data available, so having domain only in the PI is quite reasonable.
> 
> Thus, the correct answer to me for domain for a device is either zero
> or multiple.  To recommend one as a compromise seeks OK.
> I second Juergen's line of reasoning that it is quite unnecessary and
> not justified to make the framework change to single at this time.
> 
> Thanks,
> 
> --Bruce
> 
> --
> 
> Bruce Nordman
> nordman.lbl.gov

---

From: Brad Schoening <[email-masked]>
Date: Fri, 31 Jan 2014 15:57:07 +0000

HI Thomas,

As Mouli mentioned in a separate email, the use case you mention can be address with keywords.  A single domain + keywords gives flexibility in characterizing your environment.  Given this, I think the current single domain model has shown it address all the specific concerns raised  thus far.

Best Regards,

Brad

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
[email-masked] | www.coraid.com<http://www.coraid.com>
Coraid: Redefining Storage

From: Thomas Dietz <[email-masked]<mailto:[email-masked]>>
Date: Fri, 31 Jan 2014 08:15:36 +0000
To: Brad Schoening <[email-masked]<mailto:[email-masked]>>, Bruce Nordman <[email-masked]<mailto:[email-masked]>>, eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Dear Brad, all,

first of all I second Jürgen’s view that we should not artificially limit ourselves if there is no technical reason.

And what the discussion below shows is exactly the reason for that. The definition of the domain leaves some room for interpretation. Thus, IMHO it should be allowed to have an implementation of a domain that allows that objects are part of more than one domain. You could define the domain as a sort of “geographical domain” and have a building that get controlled by the owner and some rental units that are controlled by the tenant. This would imply that the same object are part of two different domain. And this example would match in my opinion the definition of domain in the framework document.

Best Regards,

Thomas

--
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014
Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB

Regards,

Brad

Thanks,

--Bruce

---

From: Benoit Claise <[email-masked]>
Date: Fri, 31 Jan 2014 18:21:15 +0100

Dear all,

I support the chairs decision based on the following facts, which I 
mentioned already on the list.

EMAN-FRAMEWORK:

This sentence doesn't reflect what was discussed at
http://www.ietf.org/mail-archive/web/eman/current/msg02033.html

And, most importantly, 

    *** Scalar vs Vector

The information model is the key part of the framework. The domain was 
always a string, and is still a string in the latest version. A comma 
separated value in a string is a pain from a NMS point of view.  If we 
needed a vector, it would have a vector in the information model. This 
also highlights the discrepancy in the EMAN-FMWK.
I understand that this editorial mistake has got some consequences. The 
EMAN-FRAMEWORK authors are  collectively responsible for this mistake. 
As one of them, sorry.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 31 Jan 2014 18:32:47 +0100

Hi Jürgen,

I would appreciate if you could stop referring to EnergyWise 
limitations, as this is a false statement.
True, we have implementations: that project started in 2008. The tech 
lead for that project asked all of our partners (more than 100), and 
nobody wanted to have one device or energy objects part of one device 
(such as power supply) in multiple Energy Management Domains. So 6 years 
of experience and many implementations showed us it doesn't make sense. 
It's like we would manage line card 1 with snmp string1, and line card 2 
with snmp string2. In EMAN, this could be done these days with the 
keywords.

Regards, Benoit
> 1. Having a device limited to a single domain membership is a limitation/feature of Cisco's EnergyWise for which in all the long discussions we had in past year never any technical reason was given (although it was asked for multiple times).
> In the contrary, I gave use cases where it is REQUIRED to have two or more domains. An obvious example is a highly reliable server that has dual power supply. Its two power supply lines SHOULD be in different domains in order to be better protected from local power supply failures. This server should be given means to report via the MIB that it is member of two domains.
>
>> <[email-masked]> wrote:
>>
>>>