Subject: [eman] Question about entPhysicalUris

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 15 Nov 2011 18:03:30 -0600

>From draft-ietf-eman-energy-aware-mib-03:

> By the [RFC4133] definition, the entPhysicalUris contains a
> white space separated list of Uniform Resource Identifier
> (s)(URIs). For the ENERGY-AWARE-MIB compliance, every Energy
> Object instance MUST implement the entPhysicalUris from the
> ENTITY MIB [RFC4133]. The entPhysicalUris MUST contain the
> Energy Object UUID, according to [RFC4122].
> 
> As displayed in [RFC4122], the following is an example of the
> string representation of a UUID as a URN: urn:uuid:f81d4fae-
> 7dec-11d0-a765-00a0c91e6bf6.

This may be a stupid question but I would like an explanation from someone more knowledgable than myself on this point.  The proposal provided above seeks to make use of an existing field in the ENTITY MIB for EMAN purposes.  This seems fine but I want to understand how this would operate in practice.  Given this is an existing field presumably there are other management features which already utilize it per the stated conventions.

If other management activities are adding URIs to this field how do we distinguish EMAN related information found there from the information from other activities have placed there?  So if the field contains 3 URIs, how do we know which URI is related to EMAN?  Is there some reason that we don't care?

Similarly what are the chances that our placing information in this field might disrupt other areas of management which have been working fine up until now but are not written in such a way that they can tolerate our coexistence?

Are these valid concerns in this context?

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
224 Brookhill Drive
Gahanna, OH  43230
Email: [email-masked]
Phone: 614 718 6308

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Nov 2011 01:48:51 +0100

> Are these valid concerns in this context?

This object has always been a list of URIs and presumably if you look
for a UUID you look for a UUID URI and ignore the rest. I do not think
a sensible implementation will assign multiple UUIDs to a physical
entity.

/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: Benoit Claise <[email-masked]>
Date: Wed, 16 Nov 2011 09:02:41 +0800

> a sensible implementation will assign multiple UUIDs to a physical
Another question around entPhysicalUris, based on the fact that 
entPhysicalUris is read-write:
What if someone would change an Energy Object UUID?

Regards, Benoit.

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 15 Nov 2011 19:25:32 -0600

Do we need to say something about the persistence of this UUID/URI?

William F. Mielke
Alcatel-Lucent

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]] 
> Sent: Tuesday, November 15, 2011 8:03 PM
> To: Mielke, William F (Bill); [email-masked]
> Subject: Re: [eman] Question about entPhysicalUris
> 
> >> This may be a stupid question but I would like an 
> explanation from someone more knowledgable than myself on 
> this point.  The proposal provided above seeks to make use of 
> an existing field in the ENTITY MIB for EMAN purposes.  This 
> seems fine but I want to understand how this would operate in 
> practice.  Given this is an existing field presumably there 
> are other management features which already utilize it per 
> the stated conventions.
> >>
> >> If other management activities are adding URIs to this 
> field how do we distinguish EMAN related information found 
> there from the information from other activities have placed 
> there?  So if the field contains 3 URIs, how do we know which 
> URI is related to EMAN?  Is there some reason that we don't care?
> >>
> >> Similarly what are the chances that our placing 
> information in this field might disrupt other areas of 
> management which have been working fine up until now but are 
> not written in such a way that they can tolerate our coexistence?
> >>

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 15 Nov 2011 17:42:14 -0800

On Tue, Nov 15, 2011 at 5:02 PM, Benoit Claise <[email-masked]> wrote:

> ...

I assume that if the UUID changed, that the initial object would
cease to exist and a new object would appear - that is, other
systems would have no idea that the actual physical entity
for both is the same.

I can imagine there may be cases in which this is useful to
do.  This type of discussion seems like "implementation
guidance" and would be useful to record somewhere but
may not be a good fit for any of our chartered drafts.

--Bruce

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