Subject: Re: [eman] draft-claise-energy-monitoring-mib-08.txt

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 29 Jun 2011 04:42:09 -0500

Hi Juergen,

Thanks for your comments. 

We intend to update the MIB draft and submit a revised version before
the IETF based on the updated requirements draft (to be published soon)
and the feedback from the mailing list.

We shall revise based on your comments and if there are open issues to
be discussed, we shall send it to the mailing list. 

Thanks
Mouli

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Wednesday, May 25, 2011 3:07 PM
To: Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: Re: [eman] draft-claise-energy-monitoring-mib-08.txt

On Tue, May 24, 2011 at 02:44:55AM -0500, Mouli Chandramouli (moulchan)
wrote:
 
> Among other changes, the draft provides support for multiple Power
State
> Series and an IANA considerations section describing the procedure for
> adding new Power State Series and Power States within the series. Many
> thanks to all who provided comments.

        PowerStateSeries ::= TEXTUAL-CONVENTION
            STATUS          current
            DESCRIPTION
               "PowerStateSeries is a TC that describes the Power State
               Series a Power Monitor supports. IANA has created a
               registry of Power State Series supported by a Power
               Monitor entity and IANA shall administer the list of
               Power State Series.

               One byte is used to represent the Power State Series.

                      field  octets  contents             range
                      -----  ------  --------             -----
                       1       1     Power State Series   1..255

               Note:
                   the value of Power State Series in network byte
               order

               1 in the first byte indicates IEEE1621 Power State
               Series
               2 in the first byte indicates DMTF Power State Series
               3 in the first byte indicates EMAN Power State Series

             REFERENCE
                    "http://www.iana.org/assignments/eman"
                    "RFC EDITOR NOTE: please change the previous URL
                     if this is not the correct one after IANA assigned
                     it."

             SYNTAX      OCTETSTRING (SIZE(1))

Why is this an OCTET STRING (SIZE(1)) and not simply an enumerated
INTEGER? And if this is to be maintained by IANA, why not create a
IANA-POWER-SERIES-TC MIB module so that one can simply fetch the
latest version from IANA?

   New assignments in Power State Series require a Standards Action
   [RFC5226], i.e., they are to be made via Standards Track RFCs
   approved by the IESG.

This raises the bar pretty high. If some future organization defines
popular power states, do you think someone is going to go through the
trouble of producing a standards-track specification for this?

I also do not see why all objects in the pmPowerEntry are necessarily
indexed by power series - some appear to me to be rather a property of
the monitor and not the power state series the monitor happens to
support.

I also like to see more text moved from the document into DESCRIPTION
clauses. This in particular concerns the actual power state values.
There is no way to find out what power state 2 in power state series 1
means if all you have are MIB modules.

And lastly, I still prefer a design where the power states are simply
enumerated. Since you require a standard-track action to allocate a
new series and you reserved 8 bits for power state series, I fail to
see why a simple TC can not do the job equally well.

Since I started looking at the IANA considerations, I believe this text
needs to be removed:

        Additions to the MIB modules are subject to Expert Review
        [RFC5226], i.e., review by one of a group of experts designated
        by an IETF Area Director.  The group of experts MUST check the
        requested MIB objects for completeness and accuracy of the
        description.  Requests for MIB objects that duplicate the
        functionality of existing objects SHOULD be declined.  The
        smallest available OIDs SHOULD be assigned to the new MIB
        objects.  The specification of new MIB objects SHOULD follow the
        structure specified in Section 10.  and MUST be published using
        a well-established and persistent publication medium.

IETF MIB modules are not modified by Expert Review. This text looks
inconsistent with existing practice in maintaining IETF MIB modules.

/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/>