Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt

From: [email-masked]
Date: Wed, 10 Oct 2012 05:04:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Energy Management Working Group of the IETF.

	Title           : Entity MIB (Version 4)
	Author(s)       : Andy Bierman
                          Dan Romascanu
                          Juergen Quittek
                          Mouli Chandramouli
	Filename        : draft-ietf-eman-rfc4133bis-03.txt
	Pages           : 70
	Date            : 2012-10-10

Abstract:
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.  In
particular, it describes managed objects used for managing multiple
logical and physical entities managed by a single SNMP agent. This
document specifies version of the Entity MIB, which obsoletes version 3
[RFC4133].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-rfc4133bis-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 10 Oct 2012 12:14:04 +0000

Hello all, 

Based on the persuasive comments of Juergen Schoenwaelder the draft has been updated 
with a separate UUID-TC-MIB which contains the definitions of Textual conventions UUID and UUIDorZero.  
The descriptions are also modified.  

Please let us know if you have comments. 

Thanks
Andy, Dan, Juergen and Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 10, 2012 5:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt

Abstract:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Oct 2012 14:24:12 +0200

> document specifies version of the Entity MIB, which obsoletes version 3

Thanks. In the next revision of the I-D, please collapse the revision
statements; revision statements are only added for published versions
of a MIB module.

I am not sure whether the new entPhysicalUUID object should be added to the
examples or not.

This text also looks a bit garbled:

2.16.1.  MIB module addition Creation of a new MIB module IANA-ENTITY-
   MIB which makes the PhysicalIndex TC an IANA-maintained Textual
   Convention. Over time, there is the need to add new enumerated values
   for PhysicalClass.  If the syntax of IANAPhysicalClass were defined
   in this MIB module then a new version of this MIB would have to be
   re-issued in order to define new values.

There also seems confusion how the new TC is called. Is it PhysicalClass
or IANAPhysicalClass? And what has the PhysicalIndex to do with it??

Some descriptions (entPhysicalEntry, entPhysicalVendorType) talk about
entIANAPhysicalClass, which does not seem to exist anymore.

/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: Wed, 10 Oct 2012 14:33:37 +0200

Hi Juergen,

Thank you for your comments. Can we consider these comments (and other
that may follow) as Working Group Last Call comments? 

This would allow the chairs to start a WGLC and get comments also from
other WG participants for the Atlanta meeting. 

Thanks and Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Juergen Schoenwaelder
> Sent: Wednesday, October 10, 2012 2:24 PM
> To: [email-masked]
> Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt
> 
> > This memo defines a portion of the Management Information Base (MIB)
> > for use with network management protocols in the Internet community.
> > In particular, it describes managed objects used for managing
multiple
> > document specifies version of the Entity MIB, which obsoletes
version
> > 3 [RFC4133].
of
> a MIB module.
> 
> I am not sure whether the new entPhysicalUUID object should be added
to
> the examples or not.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Oct 2012 14:40:22 +0200

> other WG participants for the Atlanta meeting. 

Sure. Whatever works best to get things into a consistent shape.

/js

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 11 Oct 2012 09:05:50 +1300

Hi all:

This begins the WG Last Call for the Entity MIB (Version 4) draft.
It will end on Monday, 29 October (a week before IETF 85).

Please read it, and send your comments to the eman list.
If you think it's OK, let us know that too!

Cheers, Nevoil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 11 Oct 2012 10:19:15 +1300

Hi all:

This begins the WG Last Call for the EMAN Requirements draft.
It will end on Monday, 29 October (a week before IETF 85).

Cheers, Nevil

---

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Oct 2012 16:26:13 +0200

Dear all,

You can review the diff directly from RFC4133 by using this URL: 
http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc4133.txt&url2=http://tools.ietf.org/id/draft-ietf-eman-rfc4133bis-03.txt

Really a detail, but I'm not sure what "additional" mean in 
entPhysicalUUID. I would remove it.

entPhysicalUUID OBJECT-TYPE
     SYNTAX      UUIDorZero
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
             "This object contains additional identification information
             about the physical entity.  The object contains a Universal
             Unique Identifier, the syntax of this object must conform to
             RFC 4122, section 4.1.

             A zero length octet string is returned if no UUID
              information is known."

Note: I know where it comes from entPhysicalUris, where I believe it's 
appropriate.

Regards, Benoit (as a contributor)

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 22 Oct 2012 22:34:20 -0700

I have the following comments on the -09 version of the Requirements draft.
These comments are not sufficient to warrant a new WGLC.
I congratulate the authors on their hard work and quality product.

Only the first item (7.6)  suggests a substantive change.  Note that
deleting this
would not preclude EMAN including this feature - it just would not mandate
it.

Section 7.6.  I fail to see the need for this requirement.  One can simply
ask the other entity
for the information and avoid the substantial complexity this would entail.

Sometimes “entity” refers to a device or component (or also power
interface).  Sometimes it refers to just a device.  The latter should be
changed to “device”.

When referring to both power inlets and outlets, can simply to just power
interfaces. This occurs

in several places.

Section 5.2. Add “ only differing by the sign of their power value” to the
first sentence of section 5.2.  Purpose to clarify that there is only one
underlying concept, a PI.

The word “domain” occurs only once in the draft.  Is it clear what this is
to mean?  I suggest that a descriptive

phrase of the intended concept be included instead of this potentially
ambiguous word (I see nothing wrong

with defining and using the word in other drafts).

Sections 5.2.2 and 5.2.3 should be combined.  There needs to be just a
single list of PIs, not separated by whether they are inlets or outlets at
a particular point in time.  Also, the current language implies that an
inlet can be connected to one providing outlet; this is usual but not
strictly required – can be plural.  In any case, combining the two to just
a list of connected interfaces will eliminate this issue.

Section 5.3.3.  With the accuracy data available, it seems unnecessary to
include
the measurement method.

Section 5.5.2.  Reporting on energy used over intervals could be useful,
but even more basic is reporting of an accumulated energy use value (“meter
reading”) and a time stamp.  The best solution may be to add to 5.5.1,
since an energy value in isolation is not particularly useful – it needs to
be associated with time somehow, so a simple time stamp of the meter
reading is the most simple and basic way to do this.

Section 7 – “Accumulated” to “Aggregated”.

Note: The first author of the applicability statement reference is still
erroneous.  This is a database problem that we think has been fixed and
should be correct the next time the requirements document is updated.

In the Appendix, a level can be collapsed – A.1.1 can be come A.1.

--Bruce (as contributor)

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

---

From: Brad Schoening <[email-masked]>
Date: Tue, 23 Oct 2012 09:07:02 -0500

5.5.2<http://tools.ietf.org/html/draft-ietf-eman-requirements-09#section-5.5.2>.  Time intervals

   The standard must provide means for reporting the time interval for
   which an energy value is reported.

B.N. - Section 5.5.2.  Reporting on energy used over intervals could be useful, but even more basic is reporting of an accumulated energy use value (“meter reading”) and a time stamp.  The best solution may be to add to 5.5.1, since an energy value in isolation is not particularly useful – it needs to be associated with time somehow, so a simple time stamp of the meter reading is the most simple and basic way to do this.

Bruce,

It seems clear that the requirement allows for a single time interval acting as an odometer.   How this is done is an implementation detail. Probably best to leave 'solutions' to other documents.

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
[email-masked] | www.coraid.com<http://www.coraid.com>
Coraid: Redefining Storage

From: Bruce Nordman <[email-masked]<mailto:[email-masked]>>
Date: Tue, 23 Oct 2012 00:34:20 -0500
To: Nevil Brownlee <[email-masked]<mailto:[email-masked]>>
Cc: "eman >> \"[email-masked]<mailto:[email-masked]>\"" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] WG Last Call for draft-ietf-eman-requirements-09

Only the first item (7.6)  suggests a substantive change.  Note that deleting this
would not preclude EMAN including this feature - it just would not mandate it.

Section 7.6.  I fail to see the need for this requirement.  One can simply ask the other entity
for the information and avoid the substantial complexity this would entail.

Sometimes “entity” refers to a device or component (or also power interface).  Sometimes it refers to just a device.  The latter should be changed to “device”.

When referring to both power inlets and outlets, can simply to just power interfaces. This occurs
in several places.

Section 5.2. Add “ only differing by the sign of their power value” to the first sentence of section 5.2.  Purpose to clarify that there is only one underlying concept, a PI.

The word “domain” occurs only once in the draft.  Is it clear what this is to mean?  I suggest that a descriptive
phrase of the intended concept be included instead of this potentially ambiguous word (I see nothing wrong
with defining and using the word in other drafts).

Sections 5.2.2 and 5.2.3 should be combined.  There needs to be just a single list of PIs, not separated by whether they are inlets or outlets at a particular point in time.  Also, the current language implies that an inlet can be connected to one providing outlet; this is usual but not strictly required – can be plural.  In any case, combining the two to just a list of connected interfaces will eliminate this issue.

Section 5.3.3.  With the accuracy data available, it seems unnecessary to include
the measurement method.

Section 5.5.2.  Reporting on energy used over intervals could be useful, but even more basic is reporting of an accumulated energy use value (“meter reading”) and a time stamp.  The best solution may be to add to 5.5.1, since an energy value in isolation is not particularly useful – it needs to be associated with time somehow, so a simple time stamp of the meter reading is the most simple and basic way to do this.

Note: The first author of the applicability statement reference is still erroneous.  This is a database problem that we think has been fixed and should be correct the next time the requirements document is updated.

--Bruce (as contributor)

On Wed, Oct 10, 2012 at 2:19 PM, Nevil Brownlee <[email-masked]<mailto:[email-masked]>> wrote:

Hi all:

Cheers, Nevil

--
---------------------------------------------------------------------
 Nevil Brownlee                    Computer Science Department | ITS
 Phone: +64 9 373 7599 x88941<tel:%2B64%209%20373%207599%20x88941>             The University of Auckland
 FAX: +64 9 373 7453<tel:%2B64%209%20373%207453>   Private Bag 92019, Auckland 1142, New Zealand
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

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

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 24 Oct 2012 06:10:02 +0000

Bruce,

Thanks for your comments.
Replies inline.

Thanks
Mouli

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bruce Nordman
Sent: Tuesday, October 23, 2012 11:04 AM
To: Nevil Brownlee
Cc: eman >> "[email-masked]<mailto:[email-masked]>"
Subject: Re: [eman] WG Last Call for draft-ietf-eman-requirements-09

[ycm] I agree.  I think some more clarity on this topic would help.  Some requirements are specified for “entire entity”, some requirements for an “ entity”  and some other requirements for “power interfaces”.
[ycm] However, if a device were to have the capability, the power measurement can be implemented for an entity or a component of a device.

http://www.ietf.org/mail-archive/web/eman/current/msg01595.html

[ycm] Thanks  Mouli