Subject: Re: [eman] Entity MIBv4?

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Mon, 14 May 2012 06:45:23 -0500

Hello all,

Thanks for the responses - which seem to address how we can handle the
questions (wrt to ENTITY MIB) that came back at the WG meeting.  

>From a process point of view,  will there be an informational rfc  -
that lists the new requirements and the how those can be addressed
within ENTITY-MIB framework ? 

Thanks
Mouli 

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Thursday, April 19, 2012 3:57 PM
To: Mouli Chandramouli (moulchan)
Cc: Romascanu, Dan (Dan); MIB Doctors; [email-masked]
Subject: Re: [eman] Entity MIBv4?

On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan)
wrote:
 
> > >          -  representation of UUID compliant with rfc 4122 ?
> > 
> > Not 100% sure what this means. entPhysicalUris can contain an RFC
4122
> > UUID URN. Perhaps you are asking for a separate entPhysicalUuid
> > object. If so, I am not sure you need the extra URN verbosity.
> > 
> [[DR]] This is the only issue that seems open in my view - meaning the
> slides and discussions at the meeting did not seem to lead to a
> conclusion. Do we expect cases where both a RFC 4122 compliant UUID
> representation and also another entPhysicalUri format will be needed?
> 
> [ycm] Two possible approaches for UUID representation as given in the
> mailing list and slides 
> [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html

The question is whether it is wise to encode a UUID, which is
essentially 16 binary octets, in a representation that requires 45
octets. I am pretty optimistic that a DISPLAY-HINT definition can be
provided that renders 16 binary octets into something like
"f81d4fae-7dec-11d0-a765-00a0c91e6bf6".

/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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 May 2012 14:02:57 +0200

Do we need an informational RFC? I thought that having a 'Changes from
RFC4133' section in the text part of the rfc4133bis document that lists
the changes and the motivation for the changes would be sufficient. 

Dan

> From: Mouli Chandramouli (moulchan) [mailto:[email-masked]]
> Sent: Monday, May 14, 2012 2:45 PM
> To: Juergen Schoenwaelder
> Subject: RE: [eman] Entity MIBv4?
> 
> Hello all,
> 
> > [ycm]
http://www.ietf.org/mail-archive/web/eman/current/msg01287.html

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Mon, 14 May 2012 07:05:39 -0500

Thanks Dan.  Your suggestion of rfc4133bis makes sense. 

Regards
Mouli 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, May 14, 2012 5:33 PM
To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder
Cc: MIB Doctors; [email-masked]
Subject: RE: [eman] Entity MIBv4?

Dan

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 16 May 2012 00:22:24 -0500

As of now, the EMAN requirements has persistence of identifiers of the
Energy Object which would remain constant even after restart -
Requirement 4.3.
http://tools.ietf.org/html/draft-ietf-eman-requirements-06

One of the comments during the IETF83 EMAN WG meeting was on the need
(if any) for the persistence of time series measurements of energy,
power that are being considered. 
If the use case is revenue grade energy meters, used for billing,
persistence could be important.  

One possible scenario is, if the meter readings are read/collected by an
EMS/NMS, then the historical measured meter readings would be stored. 
Then potential loss of data would be the residual data since the last
data retrieval. 

Any thoughts. 

Thanks
Mouli

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 23 May 2012 12:45:13 -0700

I don't think the requirements need to say anything about persistence
other than the identifier.  Thus, devices would not be required to
persist other data through power cycles, though would not be
prohibited from doing so.  I think the requirements text is OK as-is.

I don't foresee EMAN being used for utility revenue grade metering,
and I think we do not mention this in the Applicability Statement.
Even if it was, the same organization would be carefully specifying the
meter and the data collection system.  I do think it possible that a
utility meter could report EMAN data to the building as a second path,
distinct from the billing reporting to the utility.
I can imagine EMAN being used within a building for billing, as to
commercial building tenants, but this would not be utility metering.
Losing track of small amounts of energy through very occasional
system restarts does not seem to be a problem to me.

Thanks,

--Bruce

On Tue, May 15, 2012 at 10:22 PM, Mouli Chandramouli (moulchan) <
[email-masked]> wrote:

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

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