Subject: Re: [eman] EMAN-FMWK: An Energy Object is part of a single Energy Management Domain

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 24 Feb 2012 10:00:44 -0800

I advise keeping the objects in one domain for a first version of the EMAN specification to keep things simple.
I don't disagree that this is possible it's just not practical.  You can always enhance the data model in a revision later if this becomes prevalent.

While it's a nice mental exercise to think of a device with redundant power sources and each power source in a different management domain it's just not prevalent in practice. After  years of setting up energy management domains I've yet to have anyone come across this.

To put this in network management terms it would be like having a switch with each power supply managed via SNMP but each within a different community.  

Doesn't happen. You just put the power sources in the same instance and the redundant power suppliers would be in the same management domain. Worse case if they are in different communities a management app will roll up or combine the information anyway.

So please keep this simple so that it can actually be used. If you put this in management apps will have to code and check for this complexity. The management apps will have to check to see if all outlets / children are in the same domain and then declare membership of the parent.  Assuming the other way around makes it much simpler especially since this data is rolled up to context and keywords more practically.

Jp

PS Any takers on a  $1 wager  you won't see it in practice.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Quittek
Sent: Friday, February 24, 2012 8:16 AM
To: Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] EMAN-FMWK: An Energy Object is part of a single Energy Management Domain

Hi all,

I would have an alternative proposal to solve Bill's issue on devices with redundant and diverse power sources.

Having an only entire devices (aka Energy Objects) may lead to problems if the energy object has multiple power inlets from different domains.

Instead of having entire energy objects as domain members, we should rather have memberships for the power interfaces of the energy objects.

Then a single energy object can have different power Interfaces (in Bill's scenario: power inlets) being member of different domains. And our energy management model would exactly match the real world scenario that Bill pointed us to.

And we can easily add this corollary: If all power interface of an energy object are in the same domain, then it is safe to state that the entire energy object is in that domain.

Thanks,
    Juergen

On 24.02.12 15:20, "Benoit Claise" <[email-masked]> wrote:

>
>  
>  
>    Dear all,
>    
>    In the current [EMAN-FMWK], we can read "An Energy Object is part of
>    a single Energy Management Domain"
>    
>    Feedback received from Bill Mielke:
>    
>    ³I don't think that this is a valid
>      assumption.
>      How do we address the case of an energy object which has redundant
>      and diverse
>      power sources for reliability, or an energy object which has
>      access to
>      alternative power sources with the ability to dynamically switch
>      between them
>      to optimize cost and/or carbon footprint impacts. Are these not
>      examples of
>      different metering domains?²
>    
>    
>    
>    
>    
>    
>    
>    
>    The Energy Domain definition has been updated, with some example
>    
>    
>    Energy
>      Management Domain
>    An
>      Energy Management Domain is a set of Energy Objects where
>      all objects in the domain are considered one unit of management.
>     
>    For
>      example, power distribution units and all of the attached
>      Energy Objects are part of the same Energy Management Domain.
>     
>    For
>      example, all EEO's drawing power from the same distribution panel
>      with the same
>      AC voltage within a building, or all EEO's in a building for which
>      there is one
>      main meter, would comprise an Energy Management Domain.
>     
>    NOTES:
>    
>    1.
>      Typically,
>      this set will have as members all EO's that are powered from the
>      same source.
>     
>    
>    
>    
>    
>    
>    
>    
>    Is this enough?
>    
>    Please let us know.
>    
>    Regards, Benoit. (contributor for [EMAN-FMWK])
>  
>
>_______________________________________________
>eman mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eman

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 27 Feb 2012 14:57:19 +0000

Hi John,

I have two points: 
1. I do not see a strong need to store on a devices which domain it is in.
2. I do indeed observe the need for having devices in two domains.

1. Why would you store the domain a device is in on the device in a MIB
object?  This is potentially dynamic information.  Whenever I change the
power supply of a server from phase 1 to phase 2, or whenever I move a
desktop phone from one wing of the building to another, I may have a
domain change.  If we have a UUID for the device, it is easy to detect a
device, identify it and map it to a proper domain in the database of the
energy management system.  Why then would I need to have a writable MIB
object where I can store the new domain the device has moved in?  Who
would do this wrork?  The technician moving the phone?  A management Who
would read this information?  Another energy management system?  This may
use different domains and create conflicts when setting its own domain
names.

2. the need for having devices in multiple domains depends on the kind of
devices you manage and the operational objectives of the operator.  If you
have just devices with single power supply, then obviously, there is no
need for memberships in multiple domains.  Also, if you just have a few
dual power servers and a generously provisioned power distribution tree,
you may not have a need to care about multiple domains.

In datacenters, the story is different.  One of the objectives there is to
balance between the three phases and it makes perfectly sense to have one
domain per phase.  Here you switch power supply from one domain to the
other in order 
to have the phases balanced.  And that's just one example.

My conclusion from point 1 and 2 is that I would re-consider if we really
want to add the complexity of storing a domain on the device?  As you say,
it would be recommendable "for a first version of the EMAN specification
to keep things simple". But if we spend the effort of complicating things
by storing domain information on devices, then we should do it right from
the beginning, cover use cases raised on the mailing list, and support
domains per power interface.

    Juergen

On 24.02.12 19:00, "John Parello (jparello)" <[email-masked]> wrote:

>I advise keeping the objects in one domain for a first version of the
>EMAN specification to keep things simple.
>I don't disagree that this is possible it's just not practical.  You can
>always enhance the data model in a revision later if this becomes
>prevalent.
>
>While it's a nice mental exercise to think of a device with redundant
>power sources and each power source in a different management domain it's
>just not prevalent in practice. After  years of setting up energy
>management domains I've yet to have anyone come across this.
>
>To put this in network management terms it would be like having a switch
>with each power supply managed via SNMP but each within a different
>community.  
>
>Doesn't happen. You just put the power sources in the same instance and
>the redundant power suppliers would be in the same management domain.
>Worse case if they are in different communities a management app will
>roll up or combine the information anyway.
>
>So please keep this simple so that it can actually be used. If you put
>this in management apps will have to code and check for this complexity.
>The management apps will have to check to see if all outlets / children
>are in the same domain and then declare membership of the parent.
>Assuming the other way around makes it much simpler especially since this
>data is rolled up to context and keywords more practically.
>
>Jp
>
>I would have an alternative proposal to solve Bill's issue on devices
>with redundant and diverse power sources.
>
>Having an only entire devices (aka Energy Objects) may lead to problems
>if the energy object has multiple power inlets from different domains.
>
>Instead of having entire energy objects as domain members, we should
>rather have memberships for the power interfaces of the energy objects.
>
>Then a single energy object can have different power Interfaces (in
>Bill's scenario: power inlets) being member of different domains. And our
>energy management model would exactly match the real world scenario that
>Bill pointed us to.
>
>And we can easily add this corollary: If all power interface of an energy
>object are in the same domain, then it is safe to state that the entire
>energy object is in that domain.
>
>Thanks,
>    Juergen
>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 27 Feb 2012 08:51:00 -0800

Hi Juergen,

We seem to be discussing two concepts. 

The power by relationship is used to indicate what devices power another. So that s a link from the supply to an inlet. That can have multiple sources and that relationship is many to one. Power source to powered.  Same pattern for metered by.

The domain is a set of devices that defines and area of management. Like a PC domain (windows) or community. This does not indicate the relationships between them.

I would agree to removing domain if perhaps the concept of the domain is covered by SNMP community. In the absence of SNMP the concept of a domain needs to be defined.

Again  it has nothing to do with the poweredby or meteredby relationships.

Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Monday, February 27, 2012 6:57 AM
To: John Parello (jparello); Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] EMAN-FMWK: An Energy Object is part of a single Energy Management Domain

Hi John,

I have two points: 

1. Why would you store the domain a device is in on the device in a MIB object?  This is potentially dynamic information.  Whenever I change the power supply of a server from phase 1 to phase 2, or whenever I move a desktop phone from one wing of the building to another, I may have a domain change.  If we have a UUID for the device, it is easy to detect a device, identify it and map it to a proper domain in the database of the energy management system.  Why then would I need to have a writable MIB object where I can store the new domain the device has moved in?  Who would do this wrork?  The technician moving the phone?  A management Who would read this information?  Another energy management system?  This may use different domains and create conflicts when setting its own domain names.

2. the need for having devices in multiple domains depends on the kind of devices you manage and the operational objectives of the operator.  If you have just devices with single power supply, then obviously, there is no need for memberships in multiple domains.  Also, if you just have a few dual power servers and a generously provisioned power distribution tree, you may not have a need to care about multiple domains.

In datacenters, the story is different.  One of the objectives there is to balance between the three phases and it makes perfectly sense to have one domain per phase.  Here you switch power supply from one domain to the other in order to have the phases balanced.  And that's just one example.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 27 Feb 2012 19:19:24 +0000

Hi John, 

We are not discussing different concepts.  At least no concepts that are
so far away from each other.  I am not at all discussing device
relationships.  But maybe we disagree on what a domain is and what it
would be good for.

Similar to you, I see a domain as a mean for grouping devices.  But we
have not yet defined what a group serves for.  One of my assumptions was
that the energy management system would have functions to report and act
on a domain, such as reporting total energy and power for a domain,
powering a domain to a lower energy state, etc.  Is this rather in line or
in conflict with your notion of the domain concept?

The second point to be addressed is whether or not a domain should/need to
be stored on the member device.  This question is linked with the
questions "Who sets the domain on a devices?" and "Who reads the domain of
a device?".

And yes, it does not necessarily have anything to do with a powering
relationship.  However, sometimes it may be a good idea having a domain
defined as the set of all devices in the same power distribution tree.
Then you can report on that tree separate from others.  This leads to my
datacenter scenario, where it may make sense to have domains per phase.

Cheers,
    Juergen

On 27.02.12 17:51, "John Parello (jparello)" <[email-masked]> wrote:

>The power by relationship is used to indicate what devices power another.
>So that s a link from the supply to an inlet. That can have multiple
>sources and that relationship is many to one. Power source to powered.
>Same pattern for metered by.
>
>The domain is a set of devices that defines and area of management. Like
>a PC domain (windows) or community. This does not indicate the
>relationships between them.
>
>I would agree to removing domain if perhaps the concept of the domain is
>covered by SNMP community. In the absence of SNMP the concept of a domain
>needs to be defined.
>
>devices you manage and the operational objectives of the operator.  If
>you have just devices with single power supply, then obviously, there is
>no need for memberships in multiple domains.  Also, if you just have a
>few dual power servers and a generously provisioned power distribution
>tree, you may not have a need to care about multiple domains.
>
>In datacenters, the story is different.  One of the objectives there is
>to balance between the three phases and it makes perfectly sense to have
>one domain per phase.  Here you switch power supply from one domain to
>the other in order to have the phases balanced.  And that's just one
>example.
>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Feb 2012 00:24:31 +0100

Juergen,

> use different domains and create conflicts when setting its own domain
I see more and more often this discussion of where should the
intelligence be: in the NMS with Stupid (read Simple from SNMP) devices,
versus in the devices themselves.
If we had only one NMS, the intelligence might be in the NMS. However,
it's not the case. Simply NMS and EnMS are different beasts.
Personally, I'm in favor of putting more intelligence in the devices

Note: I don't understand your argument of being dynamic.
However, don't we have the solution with the sentence "This object
specifies a zero-length string value if no Energy Management Domain name
is configured." in the following object.

      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's network management system to the next re-
               initialization."

In other words, if you don't want to use, put a zero-length string.

Regards, Benoit.

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 28 Feb 2012 00:49:52 -0600

The idea of devices grouped by the same power distribution tree - would be one special case of the use the "domain" concept.

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Quittek
Sent: Tuesday, February 28, 2012 12:49 AM
To: John Parello (jparello); Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] EMAN-FMWK: An Energy Object is part of a single Energy Management Domain

Hi John, 

Cheers,
    Juergen

---

From: Rolf Winter <[email-masked]>
Date: Tue, 28 Feb 2012 08:28:04 +0000

We should at least make things that make devices more intelligent optional to implement since we want to support really, really simple devices like devices that can only report the state they are in. 

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Benoit Claise
> Sent: Dienstag, 28. Februar 2012 00:25
> To: Juergen Quittek
> Cc: eman mailing list
> > 1. Why would you store the domain a device is in on the device in a
> > MIB object?  This is potentially dynamic information.  Whenever I
> > change the power supply of a server from phase 1 to phase 2, or
> > whenever I move a desktop phone from one wing of the building to
> > another, I may have a domain change.  If we have a UUID for the
> > device, it is easy to detect a device, identify it and map it to a
> > proper domain in the database of the energy management system.  Why
> > then would I need to have a writable MIB object where I can store the
> > new domain the device has moved in?  Who would do this wrork?  The
> > technician moving the phone?  A management Who would read this
> > information?  Another energy management system?  This may use
> > different domains and create conflicts when setting its own domain
> names.
> specifies a zero-length string value if no Energy Management Domain
> name is configured." in the following object.
> 
>       eoDomainName OBJECT-TYPE
>             SYNTAX          SnmpAdminString
>             MAX-ACCESS      read-write
>             STATUS          current
>             DESCRIPTION
> > 2. the need for having devices in multiple domains depends on the
> kind
> > of devices you manage and the operational objectives of the operator.
> > If you have just devices with single power supply, then obviously,
> > there is no need for memberships in multiple domains.  Also, if you
> > just have a few dual power servers and a generously provisioned power
> > distribution tree, you may not have a need to care about multiple
> domains.
> >
> > In datacenters, the story is different.  One of the objectives there
> > is to balance between the three phases and it makes perfectly sense
> to
> > have one domain per phase.  Here you switch power supply from one
> > domain to the other in order to have the phases balanced.  And that's
> > just one example.
> >
> >
> > My conclusion from point 1 and 2 is that I would re-consider if we
> > really want to add the complexity of storing a domain on the device?
> > As you say, it would be recommendable "for a first version of the
> EMAN
> > specification to keep things simple". But if we spend the effort of
> > complicating things by storing domain information on devices, then we
> > should do it right from the beginning, cover use cases raised on the
> > mailing list, and support domains per power interface.
> >
> >     Juergen
> >
> >
> >
> >> I don't disagree that this is possible it's just not practical.  You
> >> can always enhance the data model in a revision later if this
> becomes
> >> prevalent.
> >>
> >> power sources and each power source in a different management domain
> >> it's just not prevalent in practice. After  years of setting up
> >> energy management domains I've yet to have anyone come across this.
> >>
> >> To put this in network management terms it would be like having a
> >> switch with each power supply managed via SNMP but each within a
> >> different community.
> >>
> >> Doesn't happen. You just put the power sources in the same instance
> >> and the redundant power suppliers would be in the same management
> domain.
> >> So please keep this simple so that it can actually be used. If you
> >> put this in management apps will have to code and check for this
> complexity.
> >> The management apps will have to check to see if all outlets /
> >> children are in the same domain and then declare membership of the
> parent.
> >> Assuming the other way around makes it much simpler especially since
> >> this data is rolled up to context and keywords more practically.
> >>
> >> Jp
> >>
> >> Having an only entire devices (aka Energy Objects) may lead to
> >> problems if the energy object has multiple power inlets from
> different domains.
> >>
> >> Bill's scenario: power inlets) being member of different domains.
> And
> >> our energy management model would exactly match the real world
> >> scenario that Bill pointed us to.
> >>
> >> And we can easily add this corollary: If all power interface of an
> >> energy object are in the same domain, then it is safe to state that
> >> the entire energy object is in that domain.
> >>
> >> Thanks,
> >>    Juergen
> >>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Feb 2012 09:36:37 +0100

On Tue, Feb 28, 2012 at 08:28:04AM +0000, Rolf Winter wrote:

> We should at least make things that make devices more intelligent
> optional to implement since we want to support really, really simple
> devices like devices that can only report the state they are in.

Frankly, I fail to see intelligence here. This seems to be a post-it
object that might help coordinate management applications. If a device
is supposed to be doing anything intelligent with this object's value,
then the elements of procedure need to be defined somewhere I think.

/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: Rolf Winter <[email-masked]>
Date: Tue, 28 Feb 2012 08:47:53 +0000

This was referring to Benoit's more general comment saying "Personally, I'm in favor of putting more intelligence in the devices" not to the domain object. 

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Dienstag, 28. Februar 2012 09:37
> To: Rolf Winter
> Cc: Benoit Claise; Juergen Quittek; eman mailing list

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Feb 2012 09:57:53 +0100

On Tue, Feb 28, 2012 at 08:47:53AM +0000, Rolf Winter wrote:

> This was referring to Benoit's more general comment saying
> "Personally, I'm in favor of putting more intelligence in the
> devices" not to the domain object.

OK, but even then, interoperable 'intelligence' requires the
definition of elements of procedure. Objects that do implementation
specific magic are of limited value for interoperability.

/js

---

From: Rolf Winter <[email-masked]>
Date: Tue, 28 Feb 2012 08:59:11 +0000

I couldn't agree more. That in effect was one of my main concerns with "importance".

> Sent: Dienstag, 28. Februar 2012 09:58
> To: Rolf Winter
> OK, but even then, interoperable 'intelligence' requires the definition
> of elements of procedure. Objects that do implementation specific magic
> are of limited value for interoperability.
> 
> /js
> 
> --

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Feb 2012 16:22:30 +0100

Hi Juergen,
> in conflict with your notion of the domain concept?
This is my understanding. Yes.

Trying to bring all this together.
The proposal at the beginning of this email thread was:

    Energy Management Domain

An Energy Management Domain is a set of Energy Objects where all objects
in the domain are considered one unit of management.

For example, power distribution units and all of the attached Energy
Objects are part of the same Energy Management Domain.

For example, all EEO's drawing power from the same distribution panel
with the same AC voltage within a building, or all EEO's in a building
for which there is one main meter, would comprise an Energy Management
Domain.

NOTES:

1. Typically, this set will have as members all EO's that are powered
from the same source

If we add to that
- "If all power interface of an energy object are in the same domain,
then it is safe to state that the entire energy object is in that
domain." (proposed by Juergen)
I would slightly rephrase this: "If all Energy Objects in the
containment tree (see ENTITY-MIB) are part of the same Energy Management
Domain, then it is safe to state that the Energy Object at the root of
that containment tree is in that Energy Management Domain ."
- If we add to this, that, if you don't want to use the Energy
Management Domain , you can just put a zero-length string in eoDomainName.

Does it work?

Now, let's come back to the initial problem:

    Feedback received from Bill Mielke:
    “I don't think that this is a valid assumption. How do we address
    the case of an energy object which has redundant and diverse power
    sources for reliability, or an energy object which has access to
    alternative power sources with the ability to dynamically switch
    between them to optimize cost and/or carbon footprint impacts. Are
    these not examples of different metering domains?” 

Distinguishing between a component and a device.
- a component: "An Energy Object is part of a single Energy Management
Domain."
We understand that this domain can change over the time.
- a device: "An Energy Object is part of a single Energy Management
Domain. If all Energy Objects in the containment tree (see ENTITY-MIB)
are part of the same Energy Management Domain, then it is safe to state
that the Energy Object at the root of that containment tree is in that
Energy Management Domain."

Are we going in the right direction?

Regards, Benoit (as a contributor for [EMAN-FMWK])
>>> Juergen Quittek

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Feb 2012 16:34:59 +0100

Hi,

Maybe the term intelligence was badly chosen. Granted.
Putting "more information in the devices so that some local or remote 
management might use it intelligently", might be more appropriate.

Is sysLocation well specified?

    "The physical location of this node (e.g., 'telephone
    closet, 3rd floor'). If the location is unknown, the
    value is the zero-length string."

Is IfName well specified?

    "The textual name of the interface. The value of this
    object should be the name of the interface as assigned by
    the local device and should be suitable for use in commands
    entered at the device's `console'. This might be a text
    name, such as `le0' or a simple port number, such as `1',
    depending on the interface naming syntax of the device. If
    several entries in the ifTable together represent a single
    interface as named by the device, then each will have the
    same value of ifName. Note that for an agent which responds
    to SNMP queries concerning an interface on some other
    (proxied) device, then the value of ifName for such an
    interface is the proxied device's local name for it.

    If there is no local name, or this object is otherwise not
    applicable, then this object contains a zero-length string."

Is ifDescr well specified?

    "A textual string containing information about the
    interface. This string should include the name of the
    manufacturer, the product name and the version of the
    interface hardware/software."

Etc...

Are these objects useful, absolutely!
Would we benefit from well defined specifications for interoperability. 
Yes!
Is this possible to have well defined specifications for those objects. 
Maybe, not sure...

Regards, Benoit (as a contributor for [EMAN-FMWK]
>> Fax:   +49 421 200 3103<http://www.jacobs-university.de/>
>

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 29 Feb 2012 12:45:48 -0800

I had originally understood that the concept of "domain" was used only to
refer
to power distribution trees, commonly from a central meter.  With this, I
agree that domain is a function of the wiring topology and therefore is
associated with power interfaces.  If, and only if, ALL power interfaces for
a device share the same domain, then the device itself is part of that
domain.
Note that this applies to power outlets as well as power inlets.  Thus, a
device
that IS the central meter (e.g. in a subpanel), is in fact not in the
domain as
the devices it supplies, as the power inlet to that device is in the domain
of
whatever power distribution tree supplies it.  Since it has interfaces in
different
domains, its domain would be undefined.

I now understand that "domain" as described here is to be used in any way
that the facility manager wants to, and while using it for the power
distribution
labeling will be a common usage (and so the above would apply), any
other usage is also possible.  In this definition, the entire device is in
a single
domain (which may be blank).  Interfaces and other components can be
seen as inheriting the domain value from the device they are a part of,
but this is duplicative, and since there will be other attributes that only
devices have, unnecessary.

It is worth noting that the management system can compute "power
distribution domains"
from its knowledge of wiring topology and where meters are located.

All of the above is independent of whether domain should be included or not.
At this point, it seems we have three variables with solely user-defined
meaning:
DomainName, RoleDescription, and Keywords.  It would seem helpful to be
able to consolidate these to fewer than three (Keywords seems the most
generic).  Further, I assume that all these only apply to entire devices,
not to
interfaces or other components.

--Bruce (as contributor)

2012/2/28 Benoit Claise <[email-masked]>

> For example, all EEO's drawing power from the same distribution panel with
> the same AC voltage within a building, or all EEO's in a building for which
> there is one main meter, would comprise an Energy Management Domain.
>
>
>
> NOTES:
>             1. Typically, this set will have as members all EO's that are
> powered from the same source
>
> If we add to that
> - "If all power interface of an energy object are in the same domain, then
> it is safe to state that the entire energy object is in that domain."
> (proposed by Juergen)
> I would slightly rephrase this: "If all Energy Objects in the containment
> tree (see ENTITY-MIB) are part of the same Energy Management Domain, then
> it is safe to state that the Energy Object at the root of that containment
> tree is in that Energy Management Domain ."
> - If we add to this, that, if you don't want to use the Energy Management
> Domain , you can just put a zero-length string in eoDomainName.
>
> Does it work?
>
> In the current [EMAN-FMWK], we can read "An Energy Object is part of a
> single Energy Management Domain"
>
> “I don't think that this is a valid assumption. How do we address the case
> of an energy object which has redundant and diverse power sources for
> reliability, or an energy object which has access to alternative power
> sources with the ability to dynamically switch between them to optimize
> cost and/or carbon footprint impacts. Are these not examples of different
> metering domains?”
>
> Domain. If all Energy Objects in the containment tree (see ENTITY-MIB) are
> part of the same Energy Management Domain, then it is safe to state that
> the Energy Object at the root of that containment tree is in that Energy
> Management Domain."
>
> On 27.02.12 17:51, "John Parello (jparello)" <[email-masked]> <[email-masked]> wrote:
>
>
>  Hi Juergen,
>
> From: Juergen Quittek [mailto:[email-masked] <[email-masked]>]
> On 24.02.12 19:00, "John Parello (jparello)" <[email-masked]> <[email-masked]> wrote:
>
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf Of
> Juergen Quittek
> On 24.02.12 15:20, "Benoit Claise" <[email-masked]> <[email-masked]> wrote:
>
>
>
>
>    Dear all,
>
> eman mailing [email-masked]://www.ietf.org/mailman/listinfo/eman
>
> eman mailing [email-masked]://www.ietf.org/mailman/listinfo/eman
>
>
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Brad Schoening <[email-masked]>
Date: Wed, 29 Feb 2012 15:58:26 -0600

Bruce,

This seems odd.  How would a management system know the wiring topology with present technology?

"It is worth noting that the management system can compute "power distribution domains"
from its knowledge of wiring topology and where meters are located."

e: [email-masked] ⟐ m: 917-304-7190

<http://www.coraid.com/> Redefining Storage Economics

From: Bruce Nordman <[email-masked]<mailto:[email-masked]>>
Date: Wed, 29 Feb 2012 14:45:48 -0600
To: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Cc: eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] EMAN-FMWK: An Energy Object is part of a single Energy Management Domain

I had originally understood that the concept of "domain" was used only to refer
to power distribution trees, commonly from a central meter.  With this, I
agree that domain is a function of the wiring topology and therefore is
associated with power interfaces.  If, and only if, ALL power interfaces for
a device share the same domain, then the device itself is part of that domain.
Note that this applies to power outlets as well as power inlets.  Thus, a device
that IS the central meter (e.g. in a subpanel), is in fact not in the domain as
the devices it supplies, as the power inlet to that device is in the domain of
whatever power distribution tree supplies it.  Since it has interfaces in different
domains, its domain would be undefined.

I now understand that "domain" as described here is to be used in any way
that the facility manager wants to, and while using it for the power distribution
labeling will be a common usage (and so the above would apply), any
other usage is also possible.  In this definition, the entire device is in a single
domain (which may be blank).  Interfaces and other components can be
seen as inheriting the domain value from the device they are a part of,
but this is duplicative, and since there will be other attributes that only
devices have, unnecessary.

It is worth noting that the management system can compute "power distribution domains"
from its knowledge of wiring topology and where meters are located.

All of the above is independent of whether domain should be included or not.
At this point, it seems we have three variables with solely user-defined meaning:
DomainName, RoleDescription, and Keywords.  It would seem helpful to be
able to consolidate these to fewer than three (Keywords seems the most
generic).  Further, I assume that all these only apply to entire devices, not to
interfaces or other components.

--Bruce (as contributor)

2012/2/28 Benoit Claise <[email-masked]<mailto:[email-masked]>>
Hi Juergen,

Hi John,

Energy Management Domain
An Energy Management Domain is a set of Energy Objects where all objects in the domain are considered one unit of management.

For example, power distribution units and all of the attached Energy Objects are part of the same Energy Management Domain.

For example, all EEO's drawing power from the same distribution panel with the same AC voltage within a building, or all EEO's in a building for which there is one main meter, would comprise an Energy Management Domain.

NOTES:

            1. Typically, this set will have as members all EO's that are powered from the same source

If we add to that
- "If all power interface of an energy object are in the same domain, then it is safe to state that the entire energy object is in that domain." (proposed by Juergen)
I would slightly rephrase this: "If all Energy Objects in the containment tree (see ENTITY-MIB) are part of the same Energy Management Domain, then it is safe to state that the Energy Object at the root of that containment tree is in that Energy Management Domain ."
- If we add to this, that, if you don't want to use the Energy Management Domain , you can just put a zero-length string in eoDomainName.

Does it work?

Now, let's come back to the initial problem:
In the current [EMAN-FMWK], we can read "An Energy Object is part of a single Energy Management Domain"

Feedback received from Bill Mielke:
“I don't think that this is a valid assumption. How do we address the case of an energy object which has redundant and diverse power sources for reliability, or an energy object which has access to alternative power sources with the ability to dynamically switch between them to optimize cost and/or carbon footprint impacts. Are these not examples of different metering domains?”
Distinguishing between a component and a device.
- a component: "An Energy Object is part of a single Energy Management Domain."
    We understand that this domain can change over the time.
- a device: "An Energy Object is part of a single Energy Management Domain. If all Energy Objects in the containment tree (see ENTITY-MIB) are part of the same Energy Management Domain, then it is safe to state that the Energy Object at the root of that containment tree is in that Energy Management Domain."

Cheers,
    Juergen

On 27.02.12 17:51, "John Parello (jparello)" <[email-masked]><mailto:[email-masked]> wrote:

Hi Juergen,

Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Monday, February 27, 2012 6:57 AM
To: John Parello (jparello); Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] EMAN-FMWK: An Energy Object is part of a single
Energy Management Domain

Hi John,

I have two points:

   Juergen

On 24.02.12 19:00, "John Parello (jparello)" <[email-masked]><mailto:[email-masked]> wrote:

Jp

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Friday, February 24, 2012 8:16 AM
To: Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] EMAN-FMWK: An Energy Object is part of a single
Energy Management Domain

Hi all,

Thanks,
   Juergen

On 24.02.12 15:20, "Benoit Claise" <[email-masked]><mailto:[email-masked]> wrote:

   Dear all,

   Energy
     Management Domain
   An

   For

   For

   NOTES:

   1.
     Typically,

   Is this enough?

   Please let us know.

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/eman

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/eman

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman<http://eetd.lbl.gov/ea/nordman>
[email-masked]<mailto:[email-masked]>
510-486-7089
m: 510-501-7943

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 29 Feb 2012 14:04:29 -0800

Through the same methods as the relationship data are put into the EMAN
MIBs.

In future, it may be possible for this to be partially automated through
means as:
  http://datatracker.ietf.org/doc/draft-nordman-power-locator/

--Bruce

On Wed, Feb 29, 2012 at 1:58 PM, Brad Schoening <[email-masked]> wrote:

>  <http://www.coraid.com/> Redefining
> Storage Economics****
>
> ** **
>
> From: Bruce Nordman <[email-masked]>
> To: Benoit Claise <[email-masked]>
> Cc: eman mailing list <[email-masked]>
>
>> with the same AC voltage within a building, or all EEO's in a building for
>> which there is one main meter, would comprise an Energy Management Domain.
>>
>>
>>
>> NOTES:
>> then it is safe to state that the entire energy object is in that domain."
>> (proposed by Juergen)
>> “I don't think that this is a valid assumption. How do we address the
>> case of an energy object which has redundant and diverse power sources for
>> [email-masked]://www.ietf.org/mailman/listinfo/eman
>>