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

[Thomas Nadeau <[e-mail]>]

	
	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. 
        
       An Energy Object should be a member of a single Energy 
       Management Domain therefore one attribute is provided. 


	In order conform to the framework, The Energy-Mon MIB has 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).

	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 --------
> Subject:	Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13
> Date:	Fri, 17 Jan 2014 17:20:13 +0100
> From:	Benoit Claise <[e-mail]>
> To:	Juergen Quittek <[e-mail]>, eman mailing list <[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
>> .
>> 
> 
> 
> 
> <Attached Message Part.txt>