Subject: [OPSAWG] pmDomainName in claise-energy-monitoring-mib-03

From: john parello <[email-masked]>
Date: Mon, 24 May 2010 01:23:21 -0700

Hi Jeurgen, and All,

Apologies for the format but I did not have the original mail. I am 
copying it below for reference from the archive.

I wanted to address a few points brought up in the discussion of 
pmDomain Name and pmKeywords.

In your reply Jeurgen you ultimately stated that you thought niether 
field was needed. I'll attempt to explain why we feel they are needed.

First on the topic of pmDomainName you stated an example would be all 
phones or all devices on a floor. The pmDomain name is defined as a 
mapping to a power meter domain. This means that it would map to the 
electrical panel or a sub-meter of that distribution panel. The 
reasoning is that the devices are typically powered by one source and 
even when redundant they are powered from only one at a time.

The reason it would be configured on the device is that at the time of 
installation the operator knows the panel and source. This may or may 
not be known to a central NMS. We found that when deploying power 
monitored devices, identifying the source of power became an attribute 
that we needed configured at the source rather than at a central location.

You also stated that you felt this could be included in the pmKeywords. 
The keywords field is used to tag values so that devices can be placed 
in arbitrary groupings. Any list of keywords can be overloaded to 
contain things like location, name, type etc. When we implemented our 
reference system we started with an all encompassing list of keywords 
and then judiciously moved out values that were common and frequently 
needed. This wound up being a very small set which became name, role, 
and the metered domain. These are described in the Context section of 
the draft. These values were factored out after designs and 
consultations with NMS vendors and deployments. So we have some basis 
for having these values factored out.

They are not merely for convenience though. The concept of keywords 
winds up being very important to PDU vendors that have features where 
plugs can be grouped. The keywords gives us a generic way to associate 
groupings at the device for both networking and pdu vendors. That's the 
very nature of a standard, to create common semantics between vendors.

We also found from deployments that if the concept of keyword tagging 
and grouping is left purely to the NMS as you suggest, that the 
information provided when deploying a device is not always available to 
a central NMS station. Imagine an operator installing a PDU and creating 
groupings on the device using the PDU features. They would have to 
communicate out of band what they configured to a central NMS. that NMS 
may be managed  at a distant site or time zone. This would be analogous 
to configuring interface grouping (vlans for instance) only at an NMS 
and not at the device itself.

As for creating another mib object for this value we received feedback 
from non-network device vendors (PDU etc) that having additional tables 
was cumbersome for their implementations and that having a core set of 
values in one root object was more favorable. That said we tried to 
factor the values into appropriate objects as you can see from our 
partitioning of attributes.

As for renaming pmKeyword to pmTags thats clearly ok based on consensus.

In summary we found through our implementation and deployment that 
certain fields were necessary for convenient reporting and monitoring 
and our draft reflects that experience and a refactoring after deployments.

Thanks
John

------------
     * To: <opsawg at ietf.org>
     * Subject: [OPSAWG] pmDomainName in claise-energy-monitoring-mib-03
     * From: "Juergen Quittek" <Quittek at neclab.eu>
     * Date: Wed, 19 May 2010 10:56:26 +0200
     * Delivered-to: opsawg at core3.amsl.com
     * List-archive: <http://www.ietf.org/mail-archive/web/opsawg>
     * List-help: <mailto:[email-masked]?subject=help>
     * List-id: OPSA Working Group Mail List <opsawg.ietf.org>
     * List-post: <mailto:[email-masked]>
     * List-subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, 
<mailto:[email-masked]?subject=subscribe>
     * List-unsubscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, 
<mailto:[email-masked]?subject=unsubscribe>
     * Thread-index: Acr3MSoRKhzUkZHXTr+oXGSbCqUJMg==
     * Thread-topic: pmDomainName in claise-energy-monitoring-mib-03

Dear all,

I think object pmDomainName has become obsolete.
In the new version there is an object called pmKeywords
that can be used for much more general purposes than
object pmDomainName.

pmDomainName contains a single "domain" for the managed entity.
Examples for such a domain would be "Devices on Floor 2" or
"All Desktop Phones". However, typically managed devices can
belong to more than one domain. Therefore, I do not see the
point in having this object with just a single domain.

      pmDomainName OBJECT-TYPE
          SYNTAX          SnmpAdminString
          MAX-ACCESS      read-write
          STATUS          current
          DESCRIPTION
             "This object specifies the name of a Power Monitor Meter
             Domain for the Power Monitor.  This object specifies a
             null string if no Power Monitor Domain name is
             configured. The value of pmDomainName must remain
             constant at least from one re-initialization of the
             entity's network management system to the next re-
             initialization."
          ::= { pmEntry 7 }

The new object pmKeywords (which I would rather call pmTags)
is a comma-separated tag list. It can be used to list all domains
the device belongs too. Hence, we don't need the pmDomainName
anymore.

But anyway, I have concerns about both objects, pmDomainName
and pmKeywords. If I remember well, I explained this already
in an earlier email.

The point is that mapping a device to a domain is usually done
by the NMS. The NMS knows which domains the device is in.
But then, why would we want to store the domain on the device?
For communicating domanin names between different NMSs?

I think we need neither pmDomainName nor pmKeywords
in the energy MIB module. If there was a case for storing domain
names on managed devices, I would suggest, creating a specific
MIB module for this purpose instad of embedding it in the energy
MIB module.

     Juergen

---

From: "Dolisy, Joel" <[email-masked]>
Date: Mon, 24 May 2010 16:16:29 -0500

Hi All,

Both the concepts of domains and tags provide value to an NMS from the
perspective of populating initial values for "organizational" properties
of a managed node. Most of the time, an NMS face the issue of figuring
out how to properly categorize a newly managed element, without having
to rely on the user to configure those categories in the NMS. Policy
based system can certainly provide basic categorization, but if the
managed device itself expose "natively" categorization data, then it
makes the initial job of the NMS that much simpler, and it results in a
very smooth out-of-the-box experience for the user.
I agree on the concept that the domain is just another tag, but in
reality the downside of tags is the fact that don't carry any semantics.
Therefore I think that it makes more sense to isolate tags with specific
semantics as separate properties.

With regards to isolating those properties to a different MIB, I would
rather choose the practical sense and co-locate them with the objects
that they apply to, it makes the job of NMS a lot simpler if the data
can be gathered in one batch.

Thanks,

Joel Dolisy
SolarWinds

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of john parello
Sent: Monday, May 24, 2010 3:23 AM
To: [email-masked]
Subject: [OPSAWG] pmDomainName in claise-energy-monitoring-mib-03

Hi Jeurgen, and All,

that we needed configured at the source rather than at a central
location.

In summary we found through our implementation and deployment that 
certain fields were necessary for convenient reporting and monitoring 
and our draft reflects that experience and a refactoring after
deployments.

Thanks
John

------------

Dear all,

      pmDomainName OBJECT-TYPE
          SYNTAX          SnmpAdminString
          MAX-ACCESS      read-write
          STATUS          current
          DESCRIPTION

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

---

From: "Juergen Quittek" <[email-masked]>
Date: Sat, 29 May 2010 11:09:42 +0200

Hi John,

Thank you for your very useful explanations about deployment scenarios.
Please find comments inline.

>From your use case below, I would see a general use case for mapping devices
to domains when deploying them.

> that we needed configured at the source rather than at a central location.

Wouldn't then a more concrete managed object, such as, for example, a "power
plug ID" be much more useful than a rather vague "power domain"?

A power plug ID (and maybe a secondary power plug ID for devices with dual
supply) is a very clear concept, that would provide the information you
need. Still, it would allow the NMS to group devices easily to multiple
domains if management functions require this.

Of course this requires that the NMS has access to a power distribution plan
with a list of power plugs, their locations, etc. But this appears to be
given in your use case.

> very nature of a standard, to create common semantics between vendors.

Would such keyword/tag lists be specific for energy management or do you see
a need for them also for other management functions outside of the energy
management domain?

> and not at the device itself.

Yes, I understand the need for grouping plugs. Here again, a plug ID may
even be preferable to a domain ID.

Thanks,

    Juergen