Re: [eman] eman framework issue: How to model a meter?

[Juergen Quittek <[e-mail]>]

Hi John,

I have the same answer to you as for Brad. What you want is categories for devices, not capability modeling. 

Then my question is: do we need this? We live well in the Internet without probes having a MIB object saying: "I am a probe".

Of course, a well designed network management system may classify devices and that is probably what EnergyWise does as well for meters, consumers, etc. The question is how much of the energy management system design needs to be pushed down to the devices?

If we think we need more for energy management than we have so far needed for managing traffic in the Internet, I would like to understand why. 

Thanks,
    Juergen 

Am 20.08.2013 um 10:39 schrieb "John Parello (jparello)" <[e-mail]>:

> +1 on that Brad.
> 
> The category broadly classifies the device so a mgt system can determine if its behaving beyond its intent. For example power in the wrong direction from a producer (motor or or solar panel for example) that starts to consume.
> 
> So the category attribute answered the question "is a"
> 
> The power interface by their by their nature only measure power so it "is" not a meter but "can" measure. A meter can contain power interfaces.
> 
> So if you are looking for a capability  first I suggest not using the word "meter" to answer that question.  What you are looking for is "measure".  
> 
> A device is a "meter" and can "measure". An interface can "measure"  but "is not" a meter (a meter may contain multiple power interfaces). If you use the word "meter" there for capability then yes thats confusing but we are not doing that.
> 
> See inline
> 
> Jp
> 
> 
> 
> Sent from my iPad 
> (expect ridiculous spelling mistakes) 
> 
> On Aug 20, 2013, at 10:06 AM, "Brad Schoening" <[e-mail]> wrote:
> 
>> Juergen,
>> 
>> My experience has been that usually a meter was just a meter.  While many
>> devices such as PoE switches and PDUs can internally meter, we have to
>> recognize that there is a real use case for stand-alone metering.
>> Intelligent smart meters from vendors such as Shark, SATEC, and Crompton
>> are but a few examples of these widely used products   An ethernet switch
>> is a device who's primary purpose is networking, but may have metering
>> relationships.  But a smart meter is a device with the primary purpose of
>> metering.  
>> 
>> 
>> A common sense approach to classification should be more than adequate to
>> distinguish between products which consume energy to provide some
>> function, products that primarily produce energy, and products which are
>> designed for metering.  If we clarify that classification should involve
>> the primary purpose of a device it would this address this nit?
>> 
>> You ask "Do we need to model metering capability at all"?  Yes, because
>> smart meters, in particular sub-meters, are a key part of real time energy
>> monitoring.
>> 
>> Regards,
>> 
>> Brad
>> 
>> On 8/20/13 1:09 AM, "Juergen Quittek" <[e-mail]> wrote:
>> 
>>> Dear all, 
>>> 
>>> Here is another framework issue: How to model metering capabilities of
>>> devices?
>>> 
>>> Our framework draft (draft-ietf-eman-framework-08) models metering
>>> capability by categorizing devices and components into either a producer,
>>> a comsumer, a meter, or a distributor, see pseudocode on page 43.
>>> 
>>> I think this approach is broken. It may be useful for modeling simple
>>> scenarios, but it does not work as general model.
>>> 
>>> There are two problems with this approach.
>>> 
>>> 1. The either-or classification. A meter is typically not just a meter,
>>> but as well a consumer that consumes energy when doing it's job. A PDU
>>> that meters power at it's outlets is a meter and a distributor and a
>>> consumer. The same holds for a PoE switch. These are not either meters or
>>> consumers, they are meters and consumers and some of them are also
>>> distributors at the same time.
> [jp] for poe switch : is a "consumer", contains power interfaces that can "measure". A switch is certainly not a meter.  I proposed "distributor" as another category for pdu and/or a Poe switch. That may be clearer.
> 
> The model reads well to me with a clear distinction between category and capability to me. Don't see how that's broken unless you use meter as a capability which I agree is wrong but we don't do that.
> 
> 
> 
>>> 2. The categorization as 'meter' is only available for devices and
>>> components, not for power interfaces. But obviously a device with
>>> metering capabilities meters at (some of) its interfaces. Take the PoE
>>> switch that meters power at some or all of its PoE outlets. It would be
>>> natural to label the power interfaces at which metering capabilities are
>>> available as 'metered'. It appears strange to classify the device as
>>> 'meter'.
> [jp] you're confusing "is a" versus "can" and overloading meter in both those attributes. Meter is a classification not a capability. Measuring is the capability.
> 
> 
>>> The basic question here is: Do we need to model metering capability at
>>> all?  If yes, we should model it as an attribute, not as a category; and
>>> we should model it as attribute of the power interfaces as well.
> 
>>> BTW, if we model metering capability (monitoring), we should consequently
>>> model circuit breaker capability (control) at power interfaces as well.
> [jp] sounds like you want an additional field for capabilities. We had that in the model quite some time ago and from feedback deleted that from the Mib and framework. Are your proposing we revisit that issue and then add capability back? IMO and experience these capability type attributes need a registry and then get used rather loosely when implemented. So I think it much simpler to categorize devices and component broadly and then the capability is inferred from the presence of a measurement with caliber. Much simpler.
> 
> Jp