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

[Benoit Claise <[e-mail]>]

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:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eman
> .
>