Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Dear all,

I support the chairs decision based on the following facts, which I 
mentioned already on the list.

EMAN-FRAMEWORK:

             An Energy Object should be a member of a single Energy
             Management Domain therefore one attribute is provided.

This sentence doesn't reflect what was discussed at
http://www.ietf.org/mail-archive/web/eman/current/msg02033.html

    JP : We've discussed this at length and the approach we chose was to
    use a vector for the keywords to allow for further defining context
    you describe. We proposed scalar for the PRIMARY category and the
    PRIMARY role.

And, most importantly, 
http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which 
is the outcome of the authors call, supervised by Nevil:

    *** Scalar vs Vector
            Category  - overloaded if vectore { cons, prod, meter,
    distributor, store }
                 Primary is better received
             ex: car { biz, pleasure, commute }
            Role - need semantic not vector
            Location? (new) - clearly not vector but semantic like
    rfc4776 better geo-priv
            Domain - no problem we discussed and went with single
    Experience in filed is that scalar was only needed for these.
    ref point lldp : brad

The information model is the key part of the framework. The domain was 
always a string, and is still a string in the latest version. A comma 
separated value in a string is a pain from a NMS point of view.  If we 
needed a vector, it would have a vector in the information model. This 
also highlights the discrepancy in the EMAN-FMWK.
I understand that this editorial mistake has got some consequences. The 
EMAN-FRAMEWORK authors are  collectively responsible for this mistake. 
As one of them, sorry.

Regards, Benoit
> I agree here. I think the changes are a) quite late and b) not in line with the textual description of a domain. Have we gotten the some of the concepts all wrong/ill defined (something that was voiced before on the mailing list)? I am also puzzled about process here. I think in the last meeting I was told that no further changes were allowed (I believe). Now we make further changes.
>
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014
>
>
>> -----Original Message-----
>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
>> Sent: Donnerstag, 30. Januar 2014 22:31
>> To: eman mailing list
>> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-
>> mib-08 and draft-ietf-eman-energy-aware-mib-13
>>
>> For the Domain issue, I have always believed that the Framework draft
>> did not define the concept well.  Since it is ambiguous in the
>> Framework, it is not surprising that we are running into problems with
>> it in later stages (the MIBs for example).
>>
>> The current Framework states (6.3.6):
>>
>>     An Energy Management Domain can be any collection of Energy
>>     Objects in a deployment, but it is recommended to map 1:1
>>     with a metered or sub-metered portion of the site.
>>
>> If one uses domain in the recommended fashion, then a device that
>> receives power from two sources (each sub-metered) is definitely in two
>> different domains.
>> If one uses it differently, as is permitted, then many reasonable and
>> useful usages require more than one domain.
>>
>> Another way to think about this is that it was a flawed idea in the
>> first place that a device is in a domain at all.  It is the power
>> interface (or interfaces, for devices which receive supply from more
>> than one) that is in the domain, not the device itself.
>> An interface is more clearly in one domain.  Different types of
>> entities (devices, components, power interfaces) have different types
>> of data available, so having domain only in the PI is quite reasonable.
>>
>> Thus, the correct answer to me for domain for a device is either zero
>> or multiple.  To recommend one as a compromise seeks OK.
>> For a PI, only a single domain is needed.
>>
>> I second Juergen's line of reasoning that it is quite unnecessary and
>> not justified to make the framework change to single at this time.
>>
>> Thanks,
>>
>> --Bruce
>>
>> --
>>
>> Bruce Nordman
>> Lawrence Berkeley National Laboratory
>> nordman.lbl.gov
>> BNordman@LBL.gov
>> 510-486-7089
>> m: 510-501-7943
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> .
>