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

From: [email-masked]
Date: Wed, 03 Oct 2012 05:58:17 -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-01.txt
	Pages           : 68
	Date            : 2012-10-03

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-01

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

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

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 3 Oct 2012 13:03:58 +0000

Hello all,

Thanks for the feedback from Nevil Brownlee and Juergen Schoenwaelder. 
Based on the feedback, a new Textual Convention (TC) PhysicalUUID with the display hint has been added.  

Please let us know if you have comments.  

Thanks
Andy, Dan, Juergen  Quittek and Mouli  

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

Abstract:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Oct 2012 08:42:53 +0200

> Please let us know if you have comments.  

 PhysicalUUID ::= TEXTUAL-CONVENTION
    DISPLAY-HINT    "4x-2x-2x-1x1x-6x"
    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.

            If no additional identification information is known
            about the physical entity or supported, the object is not
            instantiated.  A zero length octet string may also be
            returned in this case."    
        SYNTAX      OCTET STRING (SIZE (16))

This is not really what I proposed. I proposed to add a separate
module defining a generic UUID textual convention that can be reused.
Having object semantics embedded in a TC seems to be a rather bad
idea. And text saying that a zero length string can be returned in the
with a (SIZE (16)) restriction is also plain wrong. What we likely
need then is a UUID TC and UUIDOrZero TC.

/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: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 4 Oct 2012 06:52:34 +0000

Hello Juergen,

Thanks for your quick review. In your previous email,  

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

you had mentioned that 
"This can go initially into the RFC 4133 update or be a separate
document, I do not really care. However, having a reusable definition
including a proper DISPLAY-HINT I think is worth the effort."

So, this TC is included in this version of the draft. 

I want to understand your comment better on the need for 2 TCs.  

Thanks
Mouli

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, October 04, 2012 12:13 PM
To: Mouli Chandramouli (moulchan)
Cc: [email-masked]
Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 4 Oct 2012 09:02:59 +0200

I think that I understand Juergen's concerns. 

1. The TC in a separate MIB module. 

Why? What is wrong with including it in the new ENTITY-MIB module. Does
it matter where it will be imported from in the future? 

2. Two TCs. I assumed that what we are defining is the UUIDOrZero TC.
Maybe we should call it so. Why do we need two TCs? Where would we use
UUID TC and where would we use UUIDOrZero TC in the ENTITY-MIB? Or you
have in mind future use?

3. Format. We used the SYNTAX and formatting that was discussed on the
list. I thought that we have consensus on it. What would be the
alternate proposal? 

Thanks and Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Mouli Chandramouli (moulchan)
> Sent: Thursday, October 04, 2012 8:53 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> On Wed, Oct 03, 2012 at 01:03:58PM +0000, Mouli Chandramouli
(moulchan)
> wrote:
> > Based on the feedback, a new Textual Convention (TC) PhysicalUUID
with
> the display hint has been added.
> >
module
> defining a generic UUID textual convention that can be reused.
idea.
> And text saying that a zero length string can be returned in the with
a
> (SIZE (16)) restriction is also plain wrong. What we likely need then
is
> a UUID TC and UUIDOrZero TC.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Oct 2012 09:30:07 +0200

> it matter where it will be imported from in the future? 

Creating a UUID-TC-MIB modules allows people to more easily find the
TC and it allows to update the generic UUID TCs indepedently from the
ENTITY-MIB. And yes, having a dependency on the ENTITY-MIB just to use
a UUID TC seems overkill to some. We have done similar things before,
see for example the URI-TC-MIB.
 
> UUID TC and where would we use UUIDOrZero TC in the ENTITY-MIB? Or you

You use a UUID TC in places where you only have to represent
UUIDs. You use the UUIDOrZero TC in places where you have to represent
a UUID or a zero-length string. Its simply useful to provide them
both. (In some MIB modules, non existing objects simply do not exist.)

> list. I thought that we have consensus on it. What would be the

Not sure what your question is. Obviously, SIZE (16) does not go well
along with a "zero-length" string.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 4 Oct 2012 09:37:44 +0200

Hi, 

Thanks for the quick answer. See in-line. 

Regards,

Dan

> Sent: Thursday, October 04, 2012 9:30 AM
> To: Romascanu, Dan (Dan)
> Cc: Mouli Chandramouli (moulchan); [email-masked]
> > Why? What is wrong with including it in the new ENTITY-MIB module.
> > Does it matter where it will be imported from in the future?
> 
TC
> and it allows to update the generic UUID TCs indepedently from the
a
> UUID TC seems overkill to some. We have done similar things before,
see
> for example the URI-TC-MIB.

[[DR]] What dependency? One does not need to implement the ENTITY-MIB. 

We've done similar things also the other way. I am not sure that the
multiplication of the MIB modules defining TCs is a good thing, to the
extreme we would get to defining each TC in a separate MIB module. The
ENTITY-MIB is quite generic, so importing from it does not seem that odd
to me. 

> You use a UUID TC in places where you only have to represent UUIDs.
You
> use the UUIDOrZero TC in places where you have to represent a UUID or
a
> zero-length string. Its simply useful to provide them both. (In some
MIB
> modules, non existing objects simply do not exist.)
> 
[[DR]] OK - so in the Entity MIB would use the UUIDOrZero TC, while the
UUID TC will be defined only to be IMPORTed by other modules in the
future. 

> along with a "zero-length" string.

[[DR]] Right. Should be SIZE (0|16) for the UUIDOrZero TC and SIZE (16)
for the UUID TC.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Oct 2012 10:07:49 +0200

> ENTITY-MIB is quite generic, so importing from it does not seem that odd

Sorry, I only see advantages in keeping truely generic definitions
separate from MIB modules defining concrete data models.
 
> UUID TC will be defined only to be IMPORTed by other modules in the

Yes, for example the energy management modules or an update of the
host resources module or ...
 
> [[DR]] Right. Should be SIZE (0|16) for the UUIDOrZero TC and SIZE (16)

Yes.

/js