Subject: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13

From: Thomas Nadeau <[email-masked]>
Date: Tue, 21 Jan 2014 15:52:38 -0500

Hi,

	I reviewed this draft as part of the MIB Doctor review on Tuesday, January 21, 2014.

	My comments inline begin with TOM:

	General Comments on the draft:

   1)  There are a number of warnings in the id-nits run. Please check and correct these.

   2)  I found a number of references inside of DESCRIPTION clauses. Remember that once the MIB is stripped out of this draft, those references have no meaning. Please either add a Reference clause below, or use an RFC/IEEE number that can easily be found.  Please go through every place where there is a reference in a DESCRIPTION clause and make this correction as I will not comment on each and every one.

   3) I generally like to include a comment after each MIB in the IMPORTS clause stating which RFC it comes from. It is a good habit since not all MIB modules are easily found for compilation.
   4) The EMAN WG and MIB Doctors consensus was to root all MIB modules under transmission, rather than under the single OID energyMIB. These modules still use the older approach, so please correct them.

   5) Here is the output from smilint on each of the modules. I do not have access to smicng, so this is the best I could do for compilation. As you can see there are a number of nits that are found that should be corrected such as importing values that are unused. Please fix these. 

IANA-ENERGY-RELATION-MIB:

[server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB
./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' is already loaded, aborting parser on this file
./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be imported from module `SNMPv2-SMI'
./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: identifier `snmpEngineID' differs from `SnmpEngineID' only in case
./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous definition of `SnmpEngineID'
./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown object identifier label `energyMIB'
./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier `mib-2' imported from module `SNMPv2-SMI' is never used
[server:libsmi-0.4.8/mibs/ietf] tnadeau% 

ENERGY-OBJECT-CONTEXT-MIB:

[server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB ./ENERGY-OBJECT-CONTEXT-MIB
./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' is already loaded, aborting parser on this file
./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be imported from module `SNMPv2-SMI'
./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: identifier `snmpEngineID' differs from `SnmpEngineID' only in case
./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous definition of `SnmpEngineID'
./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2
./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown object identifier label `energyMIB'
./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier `mib-2' imported from module `SNMPv2-SMI' is never used
./ENERGY-OBJECT-CONTEXT-MIB:79: [1] {object-identifier-unknown} unknown object identifier label `energyMIB'
./ENERGY-OBJECT-CONTEXT-MIB:6: [5] {import-unused} warning: identifier `mib-2' imported from module `SNMPv2-SMI' is never used
./ENERGY-OBJECT-CONTEXT-MIB:9: [5] {import-unused} warning: identifier `TruthValue' imported from module `SNMPv2-TC' is never used
[server:libsmi-0.4.8/mibs/ietf] tnadeau% 

     Network Working Group                                 J. Parello 
     Internet-Draft                                         B. Claise 
     Intended Status: Standards Track              Mouli Chandramouli 
     Expires: June 13, 2014                       Cisco Systems, Inc. 
                                                    December 13, 2013  

                          Energy Object Context MIB  
                     draft-ietf-eman-energy-aware-mib-13 

     Status of this Memo 

        This Internet-Draft is submitted to IETF in full conformance 
        with the provisions of BCP 78 and BCP 79.  
           
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups. Note that other groups may also distribute working 
        documents as Internet-Drafts.  
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time. It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work 
        in progress."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html 
         
        This Internet-Draft will expire on June 13, 2014.                     

     <Parello, Claise>       Expires June 13, 2014            [Page 1] 
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
     Copyright Notice 
      
        Copyright (c) 2012 IETF Trust and the persons identified as the 
        document authors. All rights reserved. 
         
        This document is subject to BCP 78 and the IETF Trust's Legal 
        Provisions Relating to IETF Documents 
        (http://trustee.ietf.org/license-info) in effect on the date of 
        publication of this document. Please review these documents 
        carefully, as they describe your rights and restrictions with 
        respect to this document. Code Components extracted from this 
        document must include Simplified BSD License text as described 
        in Section 4.e of the Trust Legal Provisions and are provided 
        without warranty as described in the Simplified BSD License. 

     Abstract 

        This document defines a subset of a Management Information Base 
        (MIB) for energy management of devices. The module addresses 
        device identification, context information, and the 
        relationships between reporting devices, remote devices, and 
        monitoring devices. 
         
     Conventions used in this document 

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
       "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
       RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
       be interpreted as described in RFC 2119 [RFC2119]. 

     Table of Contents 
         
        1. Introduction............................................... 3 
           1.1. Energy Management Document Overview....................3 
        2. The Internet-Standard Management Framework................. 4 
        3. Requirements and Use Cases................................. 4 
        4. Terminology................................................ 4 
        5. Architecture Concepts Applied to the MIB Module............ 6 
           5.1 Energy Object Identification............................8 
           5.2 Energy Object Context...................................9 
           5.3 Links to Other Identifiers.............................10 
           5.4 Energy Object Relationships............................11 
           5.5 Energy Object Identity Persistence.....................12 
        6. MIB Definitions........................................... 12 

     <Parello, Claise>       Expires  June 13, 2014            [Page 2] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        7. Implementation Status..................................... 27 
        8. Security Considerations................................... 28 
        9. IANA Considerations....................................... 29 
        10. Acknowledgement.......................................... 29 
        11. References............................................... 30 
           11.1. Normative References.................................30 
           11.2. Informative References...............................31 

     1. Introduction 

        The EMAN standards provide a specification for Energy 
        Management. This document defines a subset of a Management 
        Information Base (MIB) for use with network management protocols 
        for Energy monitoring of network devices and devices attached to 
        the network and possibly extending to devices in the industrial 
        automation setting with a network interface.  
         
        The focus of the MIB module specified in this document is on the 
        identification of Energy Objects and reporting the context and 
        relationships of Energy Objects as defined in [EMAN-FMWK]. The 
        module addresses Energy Object Identification, Energy Object 
        Context, and Energy Object Relationships. 

     1.1. Energy Management Document Overview 

        This document specifies the Energy Object Context (ENERGY-
        OBJECT-CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY-
        RELATION-MIB) modules. The Energy Object Context MIB module 
        specifies MIB objects for identification of Energy Objects, and 
        reporting context and relationship of an Energy Object. The IANA 
        Energy Relationship MIB module specifies the first version of 
        the IANA-maintained definitions of relationships between Energy 
        Objects. 
         
        This document is based on the Energy Management Framework [EMAN-
        FMWK] and meets the requirements on identification of Energy 
        Objects and their context and relationships as specified in the 
        Energy Management requirements [RFC6988]. 
                           
        A second MIB module required by the [EMAN-FMWK], the Power and 
        Energy Monitoring MIB [EMAN-MON-MIB], monitors the Energy 
        Objects for Power States, for the Power and Energy consumption. 
        Power State monitoring includes: retrieving Power States, Power 
        State properties, current Power State, Power State transitions, 
        and Power State statistics. In addition, this MIB module 

     <Parello, Claise>       Expires  June 13, 2014            [Page 3] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        provides the Power Characteristics properties of the Power and 
        Energy, along with optional characteristics. 
         
        The applicability statement document [EMAN-AS] provides the list 
        of use cases, and describes the common aspects of between 
        existing Energy standards and the EMAN standard, and shows how 
        the EMAN framework relates to other frameworks. 

     2. The Internet-Standard Management Framework 

        For a detailed overview of the documents that describe the 
        current Internet-Standard Management Framework, please refer to 
        section 7 of RFC 3410 [RFC3410]. 
         
        Managed objects are accessed via a virtual information store, 
        termed the Management Information Base or MIB. MIB objects are 
        generally accessed through the Simple Network Management 
        Protocol (SNMP). Objects in the MIB are defined using the 
        mechanisms defined in the Structure of Management Information 
        (SMI). This memo specifies MIB modules that are compliant with 
        SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, 
        RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 

     3. Requirements and Use Cases 

        Firstly, to illustrate the importance of energy monitoring in 
        networks and secondly to list some of the important areas to be 
        addressed by the Energy Management Framework, several use cases 
        and network scenarios are presented in the EMAN applicability 
        statement document [EMAN-AS]. In addition, for each scenario, 
        the target devices for energy management, and how those devices 
        powered and metered are also presented. To address the network 
        scenarios, requirements for power and energy monitoring for 
        networking devices are specified in [RFC6988]. Based on the 
        requirements [RFC6988], the [EMAN-FMWK] presents a solution 
        approach.  
         
        Accordingly, the scope of the MIB modules in this document is in 
        accordance to the requirements specified in [RFC6988] and the 
        concepts from [EMAN-FMWK].  

     4. Terminology 

      
     <Parello, Claise>       Expires  June 13, 2014            [Page 4] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        Please refer to [EMAN-FMWK] for the definitions of the following 
        terminology used in this draft: 
                 
                Energy Management  
                           
                Energy Management System (EnMS)  

TOM: This is not a great acronym as Element Management System (EMS) is commonly used.
                            
                Energy Monitoring  
                          
                Energy Control  
                 
                electrical equipment  
                            
                non-electrical equipment (mechanical equipment)  
                  
                device  
                        
                component  
         
                power inlet   
                 
                power outlet   
                              
                energy   
                            
                power  
                              
                demand   
         
                provide energy  
         
                receive energy  
                           
                meter (energy meter)  
         
                battery  
                  
                Power Interface   
                   
                Nameplate Power  
              
                Power Attributes  
                           
                Power Quality   
                            
                Power State  
                
                Power State Set  

     <Parello, Claise>       Expires  June 13, 2014            [Page 5] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 

     5. Architecture Concepts Applied to the MIB Module 

        This section describes the basic concepts specified in the 
        Energy Management Architecture [EMAN-FMWK], with specific 
        information related to the MIB modules specified in this 
        document. 
         
        The Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) MIB module 
        in this document specifies MIB objects for identification of 
        Energy Objects, and reporting context and relationship of an 
        Energy Object. The managed objects are contained in two tables 
        eoTable and eoRelationTable. 
         
        The first table eoTable focuses on link to the other MIB 
        modules, context of the Energy Object. The second table 
        eoRelationTable specifies the relationships between Energy 
        Objects. This is a simplified representation of relationship 
        between Energy Objects.  
         
        +- eoTable(2) 
           | 
           +- eoEntry(1) [entPhysicalIndex] 
           |  |  
           |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1) 
           |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2) 
           |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3) 
           |  +-- rwn MacAddress                   eoMgmtMacAddress(4) 
           |  +-- r-n InetAddressType              eoMgmtAddressType(5) 
           |  +-- r-n InetAddress                  eoMgmtAddress(6) 
           |  +-- r-n SnmpAdminString              eoMgmtDNSName(7) 
           |  +-- rwn SnmpAdminString              eoDomainName(8) 
           |  +-- rwn SnmpAdminString              eoRoleDescription(9) 
           |  +-- rwn EnergyObjectKeywordList      eoKeywords(10) 
           |  +-- rwn Integer32                    eoImportance(11) 
           |  +-- r-n INTEGER                      eoPowerCategory(12) 
           |  +-- rwn SnmpAdminString              eoAlternateKey(13) 
           |  +-- r-n INTEGER                   eoPowerInterfaceType(14) 

TOM: I am having a hard time understanding what the XXX field before the object types means here. I guess I understand the r == read and w == write but what is "n"?  I'd suggest just removing this column altogether. Whether or not the objec tis read/write/whatever doesn't seem important; what you want to get across here is the overall structure/tree of things.

           |  +- eoRelationTable(2) 
           |      |  
           |      +- eoRelationEntry(1) [entPhysicalIndex, 
        eoRelationIndex] 
           |      |  | 
           |      |  +-- --n Integer32             eoRelationIndex(1)   
           |      |  +-- --n UUIDorZero            eoRelationID(2) 

      
     <Parello, Claise>       Expires  June 13, 2014            [Page 6] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
           |      |  +-- rwn IANAEnergyRelationship       
        eoRelationship(3) 
         
        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.  

              +--------------------------+ 
              |  EO Context Information  | 
              | ------------------------ |     
              |  eoRoleDescription       | 
              |  eoKeywords              |  
              |  eoImportance            | 
              |  eoPowerCategory         | 
              |  eoPowerInterfaceType    |          
              +--------------------------+  
                     |  
                     |  
                     v        
                   +-----------------------------+  
            |---> |  EO Identification           | 
            |     |_---------------------------- | 
TOM:  Is the     ^^^ a typo?

            |     | entPhysicalIndex (*)         | 
            |     | entPhysicalName (*)          | 
            |     | entPhysicalUUID (*)          | 
            |     |                              | 
            |     | eoEthPortIndex (**)          | 
            |     | eoEthPortGrpIndex (**)       | 
            |     | eoLldpPortNumber (***)       | 
            |     | eoAlternateKey               | 
            |     |                              | 
            |     | eoMgmtMacAddress (optional)  | 
            |     | eoMgmtAddressType (optional) | 
            |     | eoMgmtAddress (optional)     | 
            |     | eoMgmtDNSName (optional)     | 
            |     | eoDomainName                 | 
            |     +------------------------------+  
            |                            
            |     +------------------------------+ 
            |---- |  EO Relationship             | 
            |     | ---------------------------- |    
            |     |  eoRelationIndex             | 
            |     |  eoRelationID                |  
            |     |  IANAEnergyRelationship      | 
            |     +------------------------------+  

      
     <Parello, Claise>       Expires  June 13, 2014            [Page 7] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 

          (*)   Compliance with the ENTITY MIB V4 [RFC6933] 
          (**)  Link with the Power over Ethernet MIB [RFC3621] 
          (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB] 

                         Figure 1: MIB Objects Grouping 

        As displayed in figure 1, the MIB objects can be classified in 
        different logical grouping of MIB objects.  

TOM: grouping -> groupings
         
        1) The Energy Object Identification. See Section 5.1 "Energy 
          Object Identification". Devices and their sub-components are 
          characterized by the power-related attributes of a physical 
          entity present in the ENTITY MIB [RFC6933]. 
        2) The Context Information. See Section 5.2 "Energy Object 
          Context" 
        3) The links to other MIB modules. See Section 5.3 "Links to 
          other Identifiers"  
        4) The Energy Object Relationships specific information. See 
          Section 5.4 
        5) The Energy Object Identity Persistence. See Section 5.5 
          "Energy Object Identity Persistence" 

     5.1 Energy Object Identification    

        Refer to the "Energy Object Information" section in [EMAN-FMWK] 
        for background information about Energy Objects.   
         
        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). entPhysicalIndex is used as 
        index for the primary Energy Object information in the ENERGY-
        OBJECT-CONTEXT-MIB module. 
          
        Every Energy Object MUST have a printable name assigned to it. 

TOM: Can you be more specific with "printable"?  Do you mean ASCII etc...? 

        Energy Objects MUST implement the entPhysicalName object 
        specified in the ENTITY-MIB [RFC6933], which must contain the 
        Energy Object name.  

      
     <Parello, Claise>       Expires  June 13, 2014            [Page 8] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy 
        Object instance MUST implement the entPhysicalUUID from the 
        ENTITY MIB [RFC6933].  

        As displayed in [RFC4122], the following is an example of the 
        string representation of a UUID as a URN: urn:uuid:f81d4fae-
        7dec-11d0-a765-00a0c91e6bf6.  

        For example, to understand the relationship between Energy 
        Object Components and Energy Objects, the ENTITY-MIB physical 
        containment tree [RFC6933] MUST be implemented. 
         
        A second example deals with one of the ENTITY-MIB extensions: if 
        the Energy Object temperature is required, the managed objects 
        from the ENTITY-SENSOR-MIB [RFC3433] should be supported. 
         
        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. Refer to the "Energy 
        Management Domain" section in [EMAN-FMWK] for background 

TOM: At present the EMAN-FMWK states that it SHOULD belong to a single domain; this is inconsistent.

        information. The eoDomainName, which is an element of the 
        eoTable, is a read-write MIB object. The Energy Management 
        Domain should map 1-1 with a metered or sub-metered portion of 

TOM: The framework uses "1:1"; perhaps you should use that too?

        the network. The Energy Management Domain MUST be configured on 
        the Energy Object. The Energy Object MAY inherit the some of the 
        domain parameters (possibly domain name, some of the context 
        information such as role or keywords, importance) from the 
        Energy Object or the Energy Management Domain MAY be configured 
        directly in an Energy Object.  
         
        When an Energy Object acts as a Power Aggregator, the Energy 
        Objects for which Power should be aggregated MUST be members of 
        the same Energy Management Domain, specified by the eoDomainName 
        MIB Object.  

TOM: Again, the MUST is inconsistent with the Framework at the present time.

     5.2 Energy Object Context 

        Refer to the "Energy Object Context" section in [EMAN-FMWK] for 
        background information. 
         
        An Energy Object must provide a value for eoImportance in the 
        range of 1...100 to help differentiate the use or relative value 
        of the device. The importance range is from 1 (least important) 
        to 100 (most important). The default importance value is 1.   

      
     <Parello, Claise>       Expires  June 13, 2014            [Page 9] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        An Energy Object can provide a set of eoKeywords. These keywords 
        are a list of tags that can be used for grouping and summary 
        reporting within or between Energy Management Domains. 
      
        An Energy Object can have Power Interfaces and those interfaces 
        can be classified as Power Inlet, Power Outlet or both.  
         
        An Energy Object can be classified based on the physical 
        properties of the Energy Object. That Energy Object can be 
        classified as consuming power or supplying power to other 
        devices or that Energy Object can perform both of those 
        functions and finally, an Energy Object can be a passive meter.   
      
        Additionally, an Energy Object can provide an eoRoleDescription 
        string that indicates the purpose the Energy Object serves in 
        the network. 

     5.3 Links to Other Identifiers    

        While the entPhysicalIndex is the primary index for all MIB 
        objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy 
        Management Systems (EnMS) must be able to make the link with the 

TOM: Do you really mean (all caps) MUST here?

        identifier(s) in other supported MIB modules. 
      
        If the Energy Object is a Power over Ethernet (PoE) port, and if 
        the Power over Ethernet MIB [RFC3621] is supported by the Energy 
        Object SNMP agent, then the Energy Object eoethPortIndex and 
        eoethPortGrpIndex MUST contain the values of pethPsePortIndex 
        and pethPsePortGroupIndex [RFC3621].  
         
        The Energy Object eoLldpPortNumber MUST contain the 
        lldpLocPortNum from the LLDP MIB [LLDP-MIB], if the LLDP-MED  
        MIB is supported on the Energy Object SNMP agent. 
         
        The intent behind the links to the other MIB module 
        identifier(s) is to correlate the instances in the different MIB 
        modules. This will allow the ENERGY-OBJECT-CONTEXT-MIB module to 
        reference other MIB modules in cases where the Power over 
        Ethernet and the LLDP MIB modules are supported by the SNMP 
        agent. Some use cases may not implement any of these two MIB 

TOM: I think you mean something like, "...may not implement either of these MIB ..."

        modules for the Energy Objects. However, in situation where any 
        of these two MIB modules are implemented, the EnMS must be able 
        to correlate the instances in the different MIB modules. 
         
        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 

     <Parello, Claise>       Expires  June 13, 2014           [Page 10] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        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. 

TOM: Do you want to use MUST here to indicate that it MUST be the zero-length string? 

     5.4 Energy Object Relationships 

        Refer to the "Energy Object Relationships" section in [EMAN-
        FMWK] for the definition and background information. 
        In order to link two Energy Objects a separate table 
        (eoRelationTable) has been introduced in this MIB module. The 
        following relationships between Energy objects have been 
        considered in the eoRelationTable.   

          Metering Relationship -> meteredBy/metering 

          Power Source Relationship -> poweredBy/powering 

          Aggregation Relationship -> aggregatedBy/aggregating  
                                        
        Each Energy object can have one or more Energy Object 
        relationships with other Energy Objects. The relations between 
        Energy Objects are specified in eoRelationTable. The 
        relationship between the Energy Objects is specified with an 
        arbitrary index and the UUID of the remote Energy Object. The 
        UUID MUST comply to the RFC 4122 specifications.  It is 
        important to note that it is possible that an Energy Object may 

TOM: may -> might

        not have an Energy Object relationship with other Energy 
        Objects.  
         
        The IANA Energy Relationship MIB module specifies the first 
        version of the IANA-maintained definitions of relationships 
        between Energy Objects, as textual conventions. This way, for 
        Energy Relationships, new textual conventions can be specified, 
        without updating the primary Energy Object Context MIB module. 
         
        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. The optional objects 
        eoMgmtMacAddress, eoMgmtAddressType eoMgmtDNSName can be used to 
        help identify the relationship between the Energy Objects and 
        other NMS objects.  These objects can be used as an alternate 

     <Parello, Claise>       Expires  June 13, 2014           [Page 11] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        key to help link the Energy Object with other keyed information 
        that may be stored within the EnMS(s).  For the optional objects 
        that may not be included in some vendor implementations, the 
        expected behavior when those objects are polled is a response 
        noSuchInstance. 

     5.5 Energy Object Identity Persistence 

        In some situations, the Energy Object identity information 
        should be persistent even after a device reload. For example, in 
        a static setup where a switch monitors a series of connected PoE 
        phones, there is a clear benefit for the EnMS if the Energy 
        Object Identification and all associated information persist, as 
        it saves a network discovery.  However, in other situations, 
        such as a wireless access point monitoring the mobile user PCs, 
        there is not much advantage to persist the Energy Object 
        Information.   The identity information of an Energy Object 
        should be persisted and there is value in the writable MIB 
        objects persisted. 

     6. MIB Definitions 

        -- ************************************************************ 
        --  
        --    
        -- This MIB is used for describing the identity and the  
        -- context information of Energy Objects in network  

TOM: "in network" -> "in a network" ?

        --  
        --    
        -- ************************************************************* 

        ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::= BEGIN 
         
        IMPORTS 
            MODULE-IDENTITY, 
            OBJECT-TYPE, 
            mib-2, 
            Integer32 
                FROM SNMPv2-SMI  
            TEXTUAL-CONVENTION, MacAddress, TruthValue 
                FROM SNMPv2-TC 
            MODULE-COMPLIANCE, 
            OBJECT-GROUP 

     <Parello, Claise>       Expires  June 13, 2014           [Page 12] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
                FROM SNMPv2-CONF 
            SnmpAdminString 
                FROM SNMP-FRAMEWORK-MIB  
            InetAddressType, InetAddress 
               FROM INET-ADDRESS-MIB                  
            entPhysicalIndex 
               FROM ENTITY-MIB     

TOM: I generally like to include a comment after each MIB stating which RFC it comes from. It is a good habit since not all MIB modules are easily found for compilation.
            UUIDorZero 
               FROM UUID-TC-MIB   

TOM: You should include a reference to RFC6933 here

            IANAEnergyRelationship 
               FROM IANA-ENERGY-RELATION-MIB;   
         
        energyObjectContextMIB MODULE-IDENTITY 
            LAST-UPDATED    "201312130000Z" 
         
            ORGANIZATION    "IETF EMAN Working Group" 
            CONTACT-INFO 
               "WG Charter: 
                http://datatracker.ietf.org/wg/eman/charter/ 
         
               Mailing Lists: 
                General Discussion: [email-masked] 
                To Subscribe: https://www.ietf.org/mailman/listinfo/eman 
                Archive: http://www.ietf.org/mail-archive/web/eman 

               Editors:        
                  John Parello  
                  Cisco Systems, Inc.  
                  3550 Cisco Way   
                  San Jose, California 95134   
                  US  
                  Phone: +1 408 525 2339  
                  Email: [email-masked]  

                  Benoit Claise 
                  Cisco Systems, Inc. 
                  De Kleetlaan 6a b1 
                  Degem 1831 
                  Belgium 
                  Phone:  +32 2 704 5622 
                  Email: [email-masked] 

                  Mouli Chandramouli 

     <Parello, Claise>       Expires  June 13, 2014           [Page 13] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
                  Cisco Systems, Inc. 
                  Sarjapur Outer Ring Road 
                  Bangalore 560103 
                  IN 
                  Phone: +91 80 4429 2409 
                  Email: [email-masked]" 

            DESCRIPTION 
               "This MIB is used for describing the identity and the  
               context information of Energy Objects" 
            REVISION 
                "201312130000Z" 
            DESCRIPTION 
               "Initial version, published as RFC YYY." 

           ::= { energyMIB 1 }    

TOM: I believe that the WG (and MIB doctors) decided to root these MIBs under transmission, as usual. Please replace this with a note to the RFC editor and IANA asking for such an assignment.
         
        energyObjectContextMIBNotifs OBJECT IDENTIFIER 
            ::= { energyObjectContextMIB 0 } 
         
        energyObjectContextMIBObjects OBJECT IDENTIFIER 
            ::= { energyObjectContextMIB 1 } 
         
        energyObjectContextMIBConform  OBJECT IDENTIFIER 
            ::= { energyObjectContextMIB 2 } 

        -- Textual Conventions 

TOM: The naming of all of these objects is unusual. The "PethPse" prefix in particular. Typically MIB variables and tables are somehow related to the module/table they are contained in.  It would be burdensome to rename every thing in the module at this point, so I would be happy if you simply defined what these prefixes meant for the uninitiated reader.      
         
        PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION 
        DISPLAY-HINT "d" 
           STATUS            current 
           DESCRIPTION 
               "This textual convention is an extension of the 
               pethPsePortIndex convention, which defines a greater than 
               zero value used to identify a power Ethernet PSE port.  
               This extension permits the additional value of zero.  The 
               semantics of the value zero are object-specific and must, 
               therefore, be defined as part of the description of any 
               object that uses this syntax.  Examples of the usage of 
               this extension are situations where none or all physical 
               entities need to be referenced." 
           SYNTAX Integer32 (0..2147483647) 

     <Parello, Claise>       Expires  June 13, 2014           [Page 14] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 

       PethPsePortGroupIndexOrZero ::= TEXTUAL-CONVENTION 
        DISPLAY-HINT "d" 
           STATUS            current 
           DESCRIPTION 
               "This textual convention is an extension of the 
               pethPsePortGroupIndex convention from the Power Over 
               Ethernet MIB [RFC3621], which defines a greater than zero 
               value used to identify group containing the port to which 
               a power Ethernet PSE is connected.  This extension 
               permits the additional value of zero.  The semantics of 
               the value zero are object-specific and must, therefore, 
               be defined as part of the description of any object that 
               uses this syntax.  Examples of the usage of this 
               extension are situations where none or all physical 
               entities need to be referenced." 
           SYNTAX Integer32 (0..2147483647) 
      
      LldpPortNumberOrZero ::= TEXTUAL-CONVENTION  
           DISPLAY-HINT "d"  
           STATUS     current  
           DESCRIPTION  
               "This textual convention is an extension of the 
               LldpPortNumber convention specified in the LLDP MIB, 
               which defines a greater than zero value used to uniquely 
               identify each port contained in the chassis (that is 
               known to the LLDP agent) by a port number.  This 
               extension permits the additional value of zero. The 
               semantics of the value zero are object-specific and must, 
               therefore, be defined as part of the description of any 
               object that uses this syntax.  Examples of the usage of 
               this extension are situations where none or all physical 
               entities need to be referenced." 
          SYNTAX Integer32(0..4096) 
      
       EnergyObjectKeywordList ::= TEXTUAL-CONVENTION 
           STATUS          current 
           DESCRIPTION 

               "A list of keywords that can be used to group Energy 
               Objects for reporting or searching. If multiple keywords 
               are present, then this string will contain all the 
               keywords separated by the ',' character. All alphanumeric 

     <Parello, Claise>       Expires  June 13, 2014           [Page 15] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
               characters and symbols (other than a comma), such as #, 
               (, $, !, and &, are allowed. White spaces before and 
               after the commas are ignored, as well as within a keyword 
               itself.  
                
               For example, if an Energy Object were to be tagged with 
               the keyword values 'hospitality' and 'guest', then the 
               keyword list will be 'hospitality,guest'." 
           SYNTAX OCTET STRING (SIZE (0..2048)) 
                
        -- Objects 
      
        eoTable OBJECT-TYPE 
            SYNTAX          SEQUENCE OF EoEntry  
            MAX-ACCESS      not-accessible 
            STATUS          current 
            DESCRIPTION 
               "This table lists Energy Objects." 
            ::= { energyObjectContextMIBObjects 1 } 
         
        eoEntry OBJECT-TYPE 
            SYNTAX          EoEntry 
            MAX-ACCESS      not-accessible 
            STATUS          current 
            DESCRIPTION 
               "An entry describes the attributes of an Energy Object.  
               Whenever a new Energy Object is added or an existing 
               Energy Object is deleted, a row in the eoTable is added 
               or deleted." 
         
             INDEX      {entPhysicalIndex } 
            ::= { eoTable 1 } 
      
        EoEntry ::= SEQUENCE { 
                eoEthPortIndex              PethPsePortIndexOrZero, 
                eoEthPortGrpIndex           PethPsePortGroupIndexOrZero, 
                eoLldpPortNumber            LldpPortNumberOrZero, 
                eoMgmtMacAddress            MacAddress, 
                eoMgmtAddressType           InetAddressType, 
                eoMgmtAddress               InetAddress, 
                eoMgmtDNSName               SnmpAdminString, 
                eoDomainName                SnmpAdminString, 
                eoRoleDescription           SnmpAdminString, 
                eoKeywords                  EnergyObjectKeywordList, 
                eoImportance                Integer32, 
                eoPowerCategory            INTEGER, 

#TOM: You should not use INTEGER; use Integer32 instead.
      
     <Parello, Claise>       Expires  June 13, 2014           [Page 16] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
                eoAlternateKey              SnmpAdminString,  
                eoPowerInterfaceType        INTEGER 

#TOM: You should not use INTEGER; use Integer32 instead.
               }                              
      
        eoEthPortIndex   OBJECT-TYPE   
            SYNTAX       PethPsePortIndexOrZero 
            MAX-ACCESS   read-only 
            STATUS       current 
            DESCRIPTION       
               "This variable uniquely identifies the power Ethernet 
               port to which the attached device is connected [RFC3621]. 
               In addition, PoE MIB should be instantiated on the 
               device. If such a power Ethernet port cannot be specified 
               or is not known then the object is zero." 
            ::= { eoEntry 1 } 

TOM: Should this have a DEFVAL of 0?
         
        eoEthPortGrpIndex   OBJECT-TYPE   
            SYNTAX       PethPsePortGroupIndexOrZero 
            MAX-ACCESS   read-only 
            STATUS       current 
            DESCRIPTION 
               "This variable uniquely identifies the group containing 
               the port to which a power Ethernet PSE is connected 
               [RFC3621]. In addition, PoE MIB should be instantiated on 
               the device. If such a group cannot be specified or is not 
               known then the object is zero." 
            ::= { eoEntry 2 } 
         
        eoLldpPortNumber   OBJECT-TYPE   
            SYNTAX       LldpPortNumberOrZero 
            MAX-ACCESS   read-only 
            STATUS       current 
            DESCRIPTION 
              "This variable uniquely identifies the port component 
              (contained in the local chassis with the LLDP agent) as 
              defined by the lldpLocPortNum in the [LLDP-MIB] and 
              [LLDP-MED-MIB]. In addition, LLDP MIB should be 

TOM: These references should not be used inline. Remember that once the MIB is stripped out of this draft, those references have no meaning. Please either add a Reference clause below, or use an RFC/IEEE number that can easily be found.  Please go through every place where there is a reference in a DESCRIPTION clause and make this correction as I will not comment on each and every one.

              instantiated on the device If such a port number cannot 
              be specified or is not known then the object is zero." 
           ::= { eoEntry 3 } 
      
        eoMgmtMacAddress OBJECT-TYPE 
            SYNTAX          MacAddress  
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
               "This object specifies a MAC address of the Energy 
               Object."  

     <Parello, Claise>       Expires  June 13, 2014           [Page 17] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
            ::= { eoEntry 4  } 
                       
        eoMgmtAddressType OBJECT-TYPE 
            SYNTAX          InetAddressType 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
              "This object specifies the eoMgmtAddress type, i.e. an 
              IPv4 address or an IPv6 address. This object MUST be 
              populated when eoMgmtAddress is populated."  
            ::= { eoEntry 5  } 
         
        eoMgmtAddress OBJECT-TYPE 
            SYNTAX          InetAddress 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
              "This object specifies the management address as an IPv4 
              address or IPv6 address of Energy Object. The IP address 
              type, i.e. IPv4 or IPv6, is determined by the 
              eoMgmtAddressType value. This object can be used as an 
              alternate key to help link the Energy Object with other 
              keyed information that may be stored within the EnMS(s)."  
            ::= { eoEntry 6  } 
      
        eoMgmtDNSName OBJECT-TYPE 
            SYNTAX          SnmpAdminString 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
               "This object specifies the DNS name of the eoMgmtAddress. 
               This object can be used as an alternate key to help link 
               the Energy Object with other keyed information that may 
               be stored within the EnMS(s)." 
            ::= { eoEntry 7  } 

TOM: Is there anything you want to say about any (suggested) format for this string?
      
        eoDomainName OBJECT-TYPE 
            SYNTAX          SnmpAdminString 
            MAX-ACCESS      read-write 
            STATUS          current 
            DESCRIPTION 
               "This object specifies the name of an Energy Management 
               Domain for the Energy Object.  This object specifies a 
               zero-length string value if no Energy Management Domain 
               name is configured. The value of eoDomainName must remain 
               constant at least from one re-initialization of the 
               entity local management system to the next re-
               initialization."  

     <Parello, Claise>       Expires  June 13, 2014           [Page 18] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
            ::= { eoEntry 8   } 

TOM: Should this be an empty string by default so that it is set into a known state?
      
        eoRoleDescription OBJECT-TYPE 
            SYNTAX          SnmpAdminString 
            MAX-ACCESS      read-write 
            STATUS          current 
            DESCRIPTION 
               "This object specifies an administratively assigned name 
               to indicate the purpose an Energy Object serves in the 
               network. 
                   
               For example, we can have a phone deployed to a lobby with 
               eoRoleDescription as 'Lobby phone'. 
                   
               This object specifies the value is the zero-length string 

TOM: specifies THAT the value...

               value if no role description is configured. 
               The value of eoRoleDescription must remain constant at 
               least from one re-initialization of the entity local  
               management system to the next re-initialization. "  
            ::= { eoEntry 9   }     
      
        eoKeywords OBJECT-TYPE 
            SYNTAX          EnergyObjectKeywordList 
            MAX-ACCESS      read-write 
            STATUS          current 
            DESCRIPTION 
               "This object specifies a list of keywords that can be 
               used to group Energy Objects for reporting or searching.  
               The value is the zero-length string if no keywords have 
               been configured. If multiple keywords are present, then 
               this string will contain all the keywords separated by 
               the ',' character. For example, if an Energy Object were 
               to be tagged with the keyword values 'hospitality' and 
               'guest', then the keyword list will be 
               'hospitality,guest'.  
      
               If write access is implemented and a value is written 
               into the instance, the agent must retain the supplied 
               value in the eoKeywords instance associated with 
               the same physical entity for as long as that entity 
               remains instantiated.  This includes instantiations 
               across all re-initializations/reboots of the local 
               management agent. "      
            ::= { eoEntry 10     } 
         
        eoImportance OBJECT-TYPE 
            SYNTAX          Integer32 (1..100) 
            MAX-ACCESS      read-write 

     <Parello, Claise>       Expires  June 13, 2014           [Page 19] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
            STATUS          current 
            DESCRIPTION  
               "This object specifies a ranking of how important the 
               Energy Object is (on a scale of 1 to 100) compared with 
               other Energy Objects in the same Energy Management 
               Domain. The ranking should provide a business or 
               operational context for the Energy Object as compared to 
               other similar Energy Objects. This ranking could be used 
               as input for policy-based network management.  

               Although network managers must establish their own 
               ranking, the following is a broad recommendation: 
                
               90 to 100 Emergency response  
               80 to 90 Executive or business critical  
               70 to 79 General or Average  
               60 to  69 Staff or support  
               40 to  59 Public or guest  
               1  to 39 Decorative or hospitality 
                
               The value of eoImportance must remain constant at least 
               from one re-initialization of the  entity local  
               management system to the next re-initialization. " 
            DEFVAL          { 1 }  
            ::= { eoEntry 11   } 
         
        eoPowerCategory OBJECT-TYPE 
            SYNTAX          INTEGER { 

#TOM: You should not use INTEGER; use Integer32 instead.

                                consumer(0), 
                                producer(1),  
                                meter(2), 
                                distributor(3), 
                                store(4) 
                            } 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
               "This object describes the Energy Object category, which 
               indicates the expected behavior or physical property of 
               the Energy Object, based on its design. An Energy Object 
               can be a consumer(0), producer(1), meter(2), 
               distributor(3) or store(4).  
         
               In some cases, a meter is required to measure the power 
               consumption. In such a case, this meter Energy Object 
               category is meter(2). If a device is functioning as a 
               distributor of Energy that category of the Energy Object 

     <Parello, Claise>       Expires  June 13, 2014           [Page 20] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
               is distributor (3). If a device is a store of electric 
               Energy the category of the device can be store (4). "  
            ::= { eoEntry 12    } 

TOM: These definitions are a bit recursive. Is there perhaps a better reference (i.e.: the framework or somethign) that better defines/describes these?
         
        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. Since Energy 
               Management Systems (EnMS) and Network Management Systems 
               (NMS) may need to correlate objects across management 
               systems, this alternate key is provided to provide such a 
               link. This optional value is intended as a foreign key or 
               alternate identifier for a manufacturer or EnMS/NMS 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.  
               The value of eoAlternateKey must remain constant at  
               least from one re-initialization of the  entity local  
               management system to the next re-initialization. "  
            ::= { eoEntry 13 } 
         
        eoPowerInterfaceType            OBJECT-TYPE 
            SYNTAX          INTEGER { 

#TOM: You should not use INTEGER; use Integer32 instead.

                                inlet(0), 
                                outlet(1),  
                                both(2)   
                            } 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
              "This object describes the Power Interface for an Energy 
              Object. A Power Interface is an interface at which a 
              Energy Object is connected to a power transmission 
              medium, at which it can in turn receive power, provide 
              power, or both. A Power Interface type can be an inlet(0) 
              or outlet(1) or both(2), respectively."   

TOM: Not sure "respectively" adds anything to the last sentence.  Also, are these states defined in the framework and if so, should there be a reference?

            ::= { eoEntry 14 } 
      
        eoRelationTable OBJECT-TYPE 
            SYNTAX          SEQUENCE OF EoRelationEntry  
            MAX-ACCESS      not-accessible 
            STATUS          current 
            DESCRIPTION 

     <Parello, Claise>       Expires  June 13, 2014           [Page 21] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
              "This table describes the relationships between Energy 
              Objects." 

TOM: This is a rather terse definition of the table. Can you add anything else here?
            ::= { energyObjectContextMIBObjects 2 } 

        eoRelationEntry OBJECT-TYPE 
            SYNTAX          EoRelationEntry 
            MAX-ACCESS      not-accessible 
            STATUS          current 
            DESCRIPTION 
              "An entry in this table describes the relationship 
              between Energy objects." 
            INDEX        { entPhysicalIndex, eoRelationIndex } 
            ::= { eoRelationTable 1 } 

        EoRelationEntry ::= SEQUENCE { 
                       eoRelationIndex    Integer32, 
                       eoRelationID       UUIDorZero, 
                       eoRelationship     IANAEnergyRelationship                
                      } 
         
        eoRelationIndex     OBJECT-TYPE 
            SYNTAX          Integer32 (0..2147483647)     
            MAX-ACCESS      not-accessible 
            STATUS          current 
            DESCRIPTION 
              "This object is an arbitrary index to identify the Energy 
              Object related to another Energy Object"  
            ::= { eoRelationEntry 1 } 
      
        eoRelationID        OBJECT-TYPE 
            SYNTAX          UUIDorZero 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
              "This object specifies the Universally Unique Identifier 
              (UUID) of the peer (other) Energy Object. The UUID must 
              comply the specifications of UUID in UUID-TC-MIB.  
               
              If UUID of the energy object is unknown or non-existent,  
              the eoRelationID will be set to a zero-length string  
              instead." 
        
        REFERENCE 
               "RFC 6933, Entity MIB - version 4,  May 2013 " 
            ::= { eoRelationEntry 2 } 

     <Parello, Claise>       Expires  June 13, 2014           [Page 22] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 

        eoRelationship      OBJECT-TYPE 
            SYNTAX          IANAEnergyRelationship 
            MAX-ACCESS      read-write  
            STATUS          current 
            DESCRIPTION 
              "This object describes the relations between Energy 
              objects. For each Energy object, the relations between 
              the other Energy objects are specified using the bitmap."  
            ::= { eoRelationEntry 3 } 
      
        -- Conformance 
         
        energyObjectContextMIBCompliances  OBJECT IDENTIFIER 
            ::= { energyObjectContextMIBConform 1   } 
         
        energyObjectContextMIBGroups  OBJECT IDENTIFIER 
            ::= { energyObjectContextMIBConform 2   } 
      
        energyObjectContextMIBFullCompliance MODULE-COMPLIANCE 
            STATUS          current 
            DESCRIPTION 
                "When this MIB is implemented with support for 
                read-write, then such an implementation can  
                claim full compliance. Such devices can then  
                be both monitored and configured with this MIB." 

            MODULE          -- this module 
            MANDATORY-GROUPS { 
                        energyObjectContextMIBTableGroup,  
                       energyObjectRelationTableGroup  
                             } 
             
           GROUP     energyObjectOptionalMIBTableGroup 
                     DESCRIPTION 
                     "A compliant implementation does not have to  
                     implement. Module Compliance of ENTITY-MIB  
                     with respect to entity4CRCompliance should  
                      be supported. " 
            ::= { energyObjectContextMIBCompliances 1 } 

        energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE 
            STATUS          current 
            DESCRIPTION 
                "When this MIB is implemented without support for 
                read-write (i.e. in read-only mode), then such an  
                implementation can claim read-only compliance.   

     <Parello, Claise>       Expires  June 13, 2014           [Page 23] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
                Such a device can then be monitored but cannot be  
                Configured with this MIB.  
                Module Compliance of ENTITY-MIB with respect to  
                entity4CRCompliance should be supported." 
            MODULE          -- this module 
         
            MANDATORY-GROUPS { 
                         energyObjectContextMIBTableGroup,  
                        energyObjectRelationTableGroup 
                             } 
         
           GROUP energyObjectOptionalMIBTableGroup 
              DESCRIPTION 
              "A compliant implementation does not have to implement  
              the managed objects in this GROUP.  
              Module Compliance of ENTITY-MIB  
              with respect to entity4CRCompliance should  
              be supported. " 
           ::= { energyObjectContextMIBCompliances 2 } 
         
        -- Units of Conformance 
         
        energyObjectContextMIBTableGroup OBJECT-GROUP 
            OBJECTS         {        
                                eoDomainName, 
                                eoRoleDescription, 
                                eoAlternateKey, 
                                eoKeywords, 
                                eoImportance, 
                                eoPowerCategory, 
                                eoPowerInterfaceType             
                            }     
            STATUS          current 
            DESCRIPTION 
                "This group contains the collection of all the objects 
                related to the EnergyObject.  
                Module Compliance of ENTITY-MIB  
                with respect to entity4CRCompliance should  
                be supported.  " 
            ::= { energyObjectContextMIBGroups 1 } 
         
        energyObjectOptionalMIBTableGroup OBJECT-GROUP 
               OBJECTS         {   
                                eoEthPortIndex, 
                                eoEthPortGrpIndex, 
                                eoLldpPortNumber, 
                                eoMgmtMacAddress, 
                                eoMgmtAddressType, 

     <Parello, Claise>       Expires  June 13, 2014           [Page 24] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
                                eoMgmtAddress, 
                                eoMgmtDNSName  
                               }     
            STATUS          current 
            DESCRIPTION 
                "This group contains the collection of all the objects 
                related to the Energy Object." 
            ::= { energyObjectContextMIBGroups 2 } 
      
        energyObjectRelationTableGroup OBJECT-GROUP 
             OBJECTS         {    
                            -- Note that object eoRelationIndex is not 
                            -- included since it is not-accessible 
         
                            eoRelationID,          
                            eoRelationship 
                             }     
              STATUS          current 
            DESCRIPTION 
                "This group contains the collection of all objects 
                specifying the relationship between Energy Objects." 
            ::= { energyObjectContextMIBGroups 3 } 
      
        END 

        IANA-ENERGY-RELATION-MIB DEFINITIONS ::= BEGIN 
             IMPORTS 
               MODULE-IDENTITY, mib-2 
                   FROM SNMPv2-SMI 
               TEXTUAL-CONVENTION 
                   FROM SNMPv2-TC; 
      
             ianaEnergyRelationMIB MODULE-IDENTITY 
               LAST-UPDATED "201312130000Z"  -- December 13, 2013 
               ORGANIZATION "IANA" 
               CONTACT-INFO "         
                             Internet Assigned Numbers Authority 
                             Postal: ICANN 
                             4676 Admiralty Way, Suite 330 
                             Marina del Rey, CA 90292 
                             Tel: +1-310-823-9358 
                             EMail: iana&iana.org" 

               DESCRIPTION 
                "This MIB module defines a TEXTUAL-CONVENTION that 
                 describes the relationships between Energy Objects. 

     <Parello, Claise>       Expires  June 13, 2014           [Page 25] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 

                 Copyright (C) The IETF Trust (2013). 
         
                 The initial version of this MIB module was published in 
                 RFC YYY; for full legal notices see the RFC itself. 
                 Supplementary information may be available at 
                 http://www.ietf.org/copyrights/ianamib.html" 

               REVISION     "201312130000Z"  -- December 13, 2013 
               DESCRIPTION  "Initial version of this MIB as published in 
                             RFC YYY."        
               ::= { energyMIB 2 } 

TOM: Re-root this OID and insert a note to IANA/RFC Editor here.   Generally for experimental MIBs you put in a dummy number here like transmission XXX so it won't compile.
      
             -- RFC Editor, please replace YYY with the IANA allocation 
             -- for this MIB module and YYY with the number of the   
             -- approved RFC 
      
             -- Textual Conventions  
      
        IANAEnergyRelationship ::= TEXTUAL-CONVENTION 
            STATUS            current 
            DESCRIPTION 
                    "An enumerated value specifies the type of  
                     relationship between Energy Objects. 
         
                    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. 
          
                    The enumeration 'meteredBy' is applicable if the  
                    Energy Object A is meteredBy Energy Object B. 
         
                    The enumeration 'metering' is applicable if the  
                    Energy Object A is metering Energy Object B. 

                    The enumeration 'aggregatedBy' is applicable if the  
                    Energy Object A is aggregatedBy Energy Object B. 
         
                    The enumeration 'aggregating' is applicable if the  
                    Energy Object A is aggregating Energy Object B." 
         
            SYNTAX      INTEGER  { 

#TOM: You should not use INTEGER; use Integer32 instead.

                         poweredBy(1),   --  power relationship  
                         powering(2), 

     <Parello, Claise>       Expires  June 13, 2014           [Page 26] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
                         meteredBy(3),   --  meter relationship  
                         metering(4),  
                         aggregatedBy(5), -- aggregation relationship  
                         aggregating(6)     
                         } 

TOM: Should there be a reference here to where these values are actually defined?
      
        END 

     7.  Implementation Status 

       [Note to RFC Editor: Please remove this section and the 
       reference to [RFC6982] before publication.] 
        
       This section records the status of known implementations of the 
       EMAN-Monitoring MIB at the time of posting of this Internet-
       Draft, and is based on a proposal described in [RFC6982]. 
           
       The description of implementations in this section is intended 
       to assist the IETF in its decision processes in progressing 
       drafts to RFCs.   
      
     11.1 SNMP Research  
      
        Organization:     SNMP Research, Inc. 
      
        Maturity:   Prototype based upon early drafts of the MIBs.  
                    We anticipate updating it to more recent  
                    documents as development schedules allow. 
      
        Coverage:   Code was generated to implement all MIB objects  
                    in ENTITY-MIB (Version 4),  
                    ENERGY-OBJECT-CONTEXT-MIB, 
                    ENERGY-OBJECT-MIB,  
                    POWER-CHARACTERISTICS-MIB, 
                    and BATTERY-MIB. 
      
        Implementation experience: The documents are implementable. 
      
        Comments:   Technical comments about the  
                    ENERGY-OBJECT-CONTEXT-MIB, 
                    ENERGY-OBJECT-MIB, and  
                    BATTERY-MIB  
                    were submitted to the EMAN Working Group  
                    E-mail list.  
      
        Licensing:  Proprietary, royalty licensing 

     <Parello, Claise>       Expires  June 13, 2014           [Page 27] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        Contact:    Alan Luchuk, luchuk at snmp.com 
      
        URL:        http://www.snmp.com/ 

     11.2 Python 
      
       Priyanka Rao mentioned on the mailing list 
       (http://www.ietf.org/mail-archive/web/eman/current/msg02063.html) 
       That she has got an python implementation. 

     8. Security Considerations  

        Some of the readable objects in these MIB modules (i.e., objects 
        with a MAX-ACCESS other than not-accessible) may be considered 
        sensitive or vulnerable in some network environments.  It is 
        thus important to control even GET and/or NOTIFY access to these 
        objects and possibly to even encrypt the values of these objects 
        when sending them over the network via SNMP.   
         
        There are a number of management objects defined in these MIB 
        modules with a MAX-ACCESS clause of read-write and/or read-
        create.  Such objects MAY be considered sensitive or vulnerable 
        in some network environments.  The support for SET operations in 
        a non-secure environment without proper protection can have a 
        negative effect on network operations.  The following are the 
        tables and objects and their sensitivity/vulnerability: 
         
          . Unauthorized changes to the eoDomainName, entPhysicalName, 
             eoRoleDescription, eoKeywords, and/or eoImportance MAY 
             disrupt power and energy collection, and therefore any 
             predefined policies defined in the network. 

        SNMP versions prior to SNMPv3 did not include adequate security. 
        Even if the network itself is secure (for example, by using 
        IPsec), there is still no secure control over who on the secure 
        network is allowed to access and GET/SET 
        (read/change/create/delete) the objects in these MIB modules. 

        It is RECOMMENDED that implementers consider the security 
        features as provided by the SNMPv3 framework (see [RFC3410], 
        section 8), including full support for the SNMPv3 cryptographic 
        mechanisms (for authentication and privacy). 

     <Parello, Claise>       Expires  June 13, 2014           [Page 28] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 

        Further, deployment of SNMP versions prior to SNMPv3 is NOT 
        RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to 
        enable cryptographic security.  It is then a customer/operator 
        responsibility to ensure that the SNMP entity giving access to 
        an instance of these MIB modules is properly configured to give 
        access to the objects only to those principals (users) that have 
        legitimate rights to GET or SET (change/create/delete) them. 

     9. IANA Considerations 

TOM: The WG agreed to not root these modules under energyMIB, and instead root each one under transmission on their own.  Please correct this.

        The MIB modules in this document uses the following IANA-

TOM: uses -> use

        assigned OBJECT IDENTIFIER values recorded in the SMI Number 
        registry.         

           Descriptor                      OBJECT IDENTIFIER value 
           ----------                      ----------------------- 

            energyMIB                         { mib-2 XXX } 

        Editor's Note (to be removed prior to publication):  IANA is 
        requested to assign a value for "XXX" under the 'mib-2' subtree 
        and to record the assignment in the SMI Numbers registry.  When 
        the assignment has been made, the RFC Editor is asked to replace 
        "XXX" (here and in the MIB module) with the assigned value and 
        to remove this note. 

        This document defines the first version of the IANA-maintained 
        IANA-ENERGY-RELATION-MIB module, maintained by IANA, which allow 
        new definitions of relationships between Energy Objects. A 
        Specification Required as defined in RFC 5226 [RFC5226], is 
        REQUIRED for each modification or addition of the energy 
        relationships. 

     10. Acknowledgement  

        We would like to thank Juergen Quittek and Juergen Schoenwalder 
        for their suggestions on the new design of eoRelationTable which 
        was a proposed solution for the open issue on the representation 
        of Energy Object as a UUIDlist.  
         
        Many thanks to Juergen Quittek for many comments on the wording, 
        text and design of the MIB thus resulting in an improved draft.  

      
     <Parello, Claise>       Expires  June 13, 2014           [Page 29] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        Many thanks to Alan Luchuk for the review of the MIB and his 
        comments. 
         
        In addition the authors thank Bill Mielke for his multiple 
        reviews, Brad Schoening and Juergen Schoenwaelder for their 
        suggestions and Michael Brown for dramatically improving this 
        draft. 
         
        And finally thanks the EMAN WG chairs: Nevil Brownlee and Tom 
        Nadeau.  
      
     11. References 

     11.1. Normative References 

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997. 
         
        [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J. 
                Schoenwaelder, Ed., "Structure of Management 
                Information Version 2 (SMIv2)", STD 58, RFC 2578, April 
                1999. 
         
        [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J. 
                Schoenwaelder, Ed., "Textual Conventions for SMIv2", 
                STD 58, RFC 2579, April 1999. 
         
        [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder, 
                "Conformance Statements for SMIv2", STD 58, RFC 2580, 
                April 1999. 
      
        [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", 
                RFC3621, December 2003. 

        [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally 
                Unique IDentifier (UUID) URN Namespace ", RFC 4122, 
                July 2005. 
      
        [RFC6933]  Bierman, A. Romascanu,D. Quittek, J. and M. 
                Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 
                2013. 
         
        [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base 
                module for LLDP configuration, statistics, local system 
                data and remote systems data components", May 2005. 

     <Parello, Claise>       Expires  June 13, 2014           [Page 30] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management Information 
                Base extension module for TIA-TR41.4 media endpoint 
                discovery information", July 2005. 
         
        [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J., 
                Dietz, T., and B. Claise  "Power and Energy Monitoring 
                MIB", draft-ietf-eman-energy-monitoring-mib-07, October 
                2013. 

     11.2. Informative References 

        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart, 
                "Introduction and Applicability Statements for Internet 
                Standard Management Framework", RFC 3410, December 
                2002. 
         
        [RFC3433]  Bierman, A., Romascanu, D., and K.C. Norseth, "Entity 
                Sensor Management Information Base", RFC 3433, December 
                2002. 
         
        [RFC5226]  Narten, T. Alverstrand, H., A. and K. McCloghrie, 
                "Guidelines for Writing an IANA Considerations Section 
                in RFCs ", BCP 26, RFC 5226, May 2008. 
         
        [RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. 
                Chandramouli, "Requirements for Energy Management", RFC 
                6988, September 2013. 
         
        [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J. 
                Quittek, "Energy Management Framework", draft-ietf-
                eman-framework-11, work in progress, November 2013. 
         
        [EMAN-AS] Schoening, B., Chandramouli, M, and B. Nordman, 
                "Energy Management (EMAN) Applicability Statement", 
                draft-ietf-eman-applicability-statement-04.txt, work in 
                progress, October 2013. 
         
        [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of 
                Running Code: The Implementation Status Section", RFC 
                6982, July 2013. 
      
     Authors' Addresses 
      
       Benoit Claise 
       Cisco Systems, Inc. 
       De Kleetlaan 6a b1 

     <Parello, Claise>       Expires  June 13, 2014           [Page 31] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
       Diegem 1813 
       BE 
          
       Phone: +32 2 704 5622 
       Email: [email-masked] 

       John Parello 
       Cisco Systems, Inc. 
       3550 Cisco Way  
       San Jose, California 95134  
       US 
          
       Phone: +1 408 525 2339 
       Email: [email-masked] 

        Mouli Chandramouli 
        Cisco Systems, Inc. 
        Sarjapur Outer Ring Road 
        Bangalore 560103  
        IN 
       
        Phone: +91 80 4429 2409   
        Email: [email-masked] 

      
     <Parello, Claise>       Expires  June 13, 2014           [Page 32]

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 21 Jan 2014 16:29:02 -0500

That is cool,but please put in a reference and (brief) explanation into the text somewhere. To the casual or new reader, it is not obvious. *)

	--Tom

> Hi Tom
> 
> Thanks. Still going through the comments. For the first one regarding EnMS acronym. That's was discussed at length and we adopted it since ISO50001 used that to describe a management system for energy (as opposed to NMS)
> 
> Not great but what's in use.
> 
> Jp
> 
> Sent from my iPad 
> (expect ridiculous spelling mistakes) 
> 
> On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" <[email-masked]> wrote:
> 
>> 
>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 21 Jan 2014 21:25:39 +0000

Hi Tom

Jp

Sent from my iPad 

On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" <[email-masked]> wrote:

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 22 Jan 2014 09:29:58 +0100

>     4) The EMAN WG and MIB Doctors consensus was to root all MIB modules under transmission, rather than under the single OID energyMIB. These modules still use the older approach, so please correc…

EMAN MIB Modules under "transmission" ????
That sounds weird to me. I would think under mib-2

Bert

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 11:28:43 +0100

On 22/01/2014 09:29, Bert Wijnen (IETF) wrote:
>>     4) The EMAN WG and MIB Doctors consensus was to root all MIB 
>> modules under transmission, rather than under the single OID 
>> energyMIB. These modules still use the older approach, so please 
>> correct them.
>
mib-2 is what's currently in the draft, like the ENTITY-MIB v4, RFC 6933.

Regards, Benoit
>
> Bert
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Jan 2014 08:07:43 -0500

That is a good catch Bert. You are right - its mib-2!

	--Tom

> On Jan 22, 2014, at 3:29 AM, "Bert Wijnen (IETF)" <[email-masked]> wrote:
> 
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Jan 2014 08:08:57 -0500

Yes mib-2 is correct. I was confused on that one.

> On Jan 22, 2014, at 5:28 AM, Benoit Claise <[email-masked]> wrote:
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 12:14:33 +0100

Hi Tom,
> TOM: Can you be more specific with "printable"?  Do you mean ASCII etc...?
This is direct cut and paste from the framework.
We had bound to SnmpAdminString, which says UTF-8
Type 	SnmpAdminString
Status 	current
MIB 	SNMP-FRAMEWORK-MIB 
<http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=SNMP-FRAMEWORK-MIB>; 
   - View Supporting Images 
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&typeName=SnmpAdminString#> 

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].

Do you want us to mention UTF-8?
> TOM: Do you really mean (all caps) MUST here?
RFC 6988:

    4.4.  Using Entity Identifiers of Existing MIB Modules

        The standard must provide means for reusing entity identifiers from
        existing standards, including at least the following:

        o  the entPhysicalIndex in the Entity MIB module [RFC6933]

        o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
           the LLDP-MED MIB module [ANSI-TIA-1057]

        o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
           Ethernet MIB [RFC3621]

        Generic means for reusing other entity identifiers must be provided.

So a MUST is right.
> TOM: Do you want to use MUST here to indicate that it MUST be the zero-length string?
Ok.
> TOM: The naming of all of these objects is unusual. The "PethPse" prefix in particular. Typically MIB variables and tables are somehow related to the module/table they are contained in.  It would b…
The logic was:

PethPsePortIndexOrZero is taken from the existing pethPsePortIndex TC
PethPsePortGroupIndexOrZero is taken from the exiting pethPsePortGroupIndex TC

> TOM: Is there anything you want to say about any (suggested) format for this string?
We will search for an existing DNS MIB and copy it
> TOM: Should this be an empty string by default so that it is set into a known state?
Make sense

Regards, Benoit

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Jan 2014 10:24:50 -0500

> We had bound to SnmpAdminString, which says UTF-8

	That is the kicker - make sure its a UTF-8 encoding specified in the description. Right now it reads like a free-form string is ok unless you go to the trouble of looking up the reference below. 

> 
> Type	SnmpAdminString
> Status	current
> MIB	 SNMP-FRAMEWORK-MIB ;   -   View Supporting Images

	OK.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jan 2014 17:31:21 +0100

> 	That is the kicker - make sure its a UTF-8 encoding specified in the description. Right now it reads like a free-form string is ok unless you go to the trouble of looking up the reference below. 

To the defense of the authors, SnmpAdminString is pretty widely used
in SNMP land and I do not recall we generally tend to repeat saying it
is a UTF-8 encoded string when it is used.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Jan 2014 12:20:53 -0500

> is a UTF-8 encoded string when it is used.

	Good point. I am %50/%50 on whether its needed to augment the text.

	--Tom

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 24 Jan 2014 11:02:55 -0800

Hi -

> From: "Thomas Nadeau" <[email-masked]>
> To: "Benoit Claise" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>; "eman mailing list" <[email-masked]>
> Sent: Friday, January 24, 2014 7:24 AM
> Subject: Re: [MIB-DOCTORS] MIB Doctor Review ofdraft-ietf-eman-energy-aware-mib-13
...
> That is the kicker - make sure its a UTF-8 encoding specified
> in the description. Right now it reads like a free-form string is
> ok unless you go to the trouble of looking up the reference below. 
...
> Type SnmpAdminString

I don't think it makes much sense for an OBJECT-TYPE making use of
a TEXTUAL-CONVENTION to repeat material from the DESCRIPTION
of the latter.  That really defeats one of the motivations for using TEXTUAL-
CONVENTIONs in the first place.

However, there's another problem, one particularly relevant for INDEX
objects:  SnmpAdminString is arguably under-specified in that it does
not specify the normalization form.  If one wants to find information using
a user-entered index value without having to go poking about in multiple
places in the table (alternate "spellings" if you will), this matters.

Randy