Subject: Re: [eman] Power States - really

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 2 Mar 2011 13:47:05 -0600

# Ted Ghose wrote:
#
# I'm dismayed that you failed to define a fine set of rule, and without that
# you are putting your model forward.

I am not sure what "fine set of rule" you are looking for. Can you please clarify?

As I said in in my previous email, I am putting some ideas out for consideration and discussion.  That was my sole intent.  I don't consider what I written to be putting a model forward, per se.  As I also said in my previous email this is not a fully cooked proposal (i.e. it is not a finished proposal with all of its various dependencies identified and fleshed out.

Is this not a proper use of the email discussion list?

# the elegant this model is, I fail to to understand what are the rule does it 
# stick to. Coming from a pure mathematics world, I'd like to define the "set"
# before "set operations"

Again, what rules are you looking for?  All I have done is to identify a few tables that might be used to expose product specific meta data which can then be used by the management applications to interface with a managed element.

Perhaps an alternative explanation might shed further light on my meaning.

The intent is that the tables I specified would allow each product to self-identify a list a power management features or capabilities which it supports (i.e. the emanCapabilitiesDefinitionsTable table).  The intent is also to allow the products to self-identify a simple set of parameters which are associated with those capabilities to enable a management application to meaningfully interact with those capabilities (i.e. the emanEnumeratedTypeTable and emanEnumeratedValuesTable tables).

All of the above exposes meta information which simply describes a set of capabilities (power related by virtue of being part of the EMAN work) that a given device supports.  It is declarative in nature and is provided to allow the management application to "discover" the unique capabilities of a given managed element.

The actual work of monitoring and controling the currently defined "state" for each such capability is accomplished via the last table (i.e. the emanProductCapabilities table).  This is the table where the management application would query for the current "capability settings" and/or where it would effect controls by setting new values within those capabilities.

When setting new values for a specific capability the meta information described above would be used to constrain the value to fall within a proper domain (e.g. a string, or an integer, or a specific selection from an enumerated type that was self-identified by the managed element).

Let me offer a few definitions (are these the rules you want?) that may aid in the interpretation of my meaning.

ProductSpecificCapabilityID:

An unsigned integer value used to uniquely identify a specific managed element defined capability.

CapabilityName:

A string value representing a human readable name for the capability.

CapabilityTypeSpecification:

This is any of String, Integer, Float, or a managed element defined EnumerationID

EnumerationID:

An unsigned integer value used to uniquely identify a specific managed element defined list of enumerated values.  The managed element can define multiple distinct enumerations and these IDs are used to distinguish one such enumeration from another.

EnumerationName:

A string value representing a human readable name for the enumeration.

ValueID:

An unsigned integer value used to uniquely identify a specific enumerated value within a given Enumeration.  The managed element can define multiple distinct values that represent the domain of alowable values for any given enumeration and these IDs are used to distinguish one such value from another within that enumeration.

ValueName:

A string value representing a human readable name for the value.  These names are expected to be unique within any given enumeration (i.e. within EnumerationID=15) but not across enumerations (i.e. the human readable name "Off" may appear in any number of enumerations, just not multiple times within the same enumeration).

So how does this all work?

In the emanCapabilitiesDefinitionsTable the managed element is simply enumerating a set of capabilities that it supports.  This is purely declarative information.  Each row in the table defines one such capability and part of that definition assigns a unique numerical ID to that capability, such as 103 or 27.  The table also defines a human readable name for that capability, such as "PortPowerControlFeature" or "FanPowerControlFeature" or "LightingDimmerControlFeature".  The exact names and the semantics of what they do is completely encapsulated within the managed element.  Lastly the table associates a specific datatype with that capability which defines the domain of meaningful values which can be assigned to that capability from an administrative perspective.

So if the operator (or management application) is expected to assign a string or an integer or a float to a specific capability then it would specify as much.

I expect, however, that in most cases these values will correspond to enumerated types.  The emanEnumeratedTypeTable and emanEnumeratedValuesTable tables provide a declarative mechanism whereby the managed element can expose any number of such enumerated types which can then be specified in the emanCapabilitiesDefinitionsTable.

If this is still unclear please feel free to ask for more clarification either publicly on the list or by contacting me directly.  I welcome any sort of feedback.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

---

From: Ted Ghose <[email-masked]>
Date: Wed, 2 Mar 2011 13:18:50 -0800

Mielke, William F (Bill) <[email-masked]> wrote:

> here the example of the rule I stated earlier:

Rule 1: device at low power state takes less power from utility power source
than at a higher state
Rule 2: device express their capability at a given state (may be % or some
measure)

What you have described is not much different from what I'm asking for. If
we have the states mapped the way you have stated, we will get the same
functionality.

thanks

-tg-