Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)

From: Randy Presuhn <[email-masked]>
Date: Fri, 23 Aug 2013 12:41:00 -0700 (GMT-07:00)

Hi -

>From: Joe Marcus Clarke <[email-masked]>
>Sent: Aug 23, 2013 11:56 AM
>To: Michael MacFaden <[email-masked]>, [email-masked]
>Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on	draft-asai-vmm-mib-04)
...
>My other comment (not quoted here) is that I was asking if some more
>explicit text could be added to the compliance section of the MIB that
>says these objects should be implemented read-write if they can be done
>in a non-persistent way (essentially incorporating text from Section 3.2
>into the MIB module itself).

Just to be absolutely clear...
Are you requesting that the normative text state that
the values assigned to these object-types SHOULD NOT
or MUST NOT persist across reboots?

I really don't like the idea of standards prohibiting
potentially useful functionality.

Randy

---

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 23 Aug 2013 15:53:35 -0400

> potentially useful functionality.

I was asking for the latter since this MIB is not about configuration.
I think it would be a POLA violation if one vendor did a persistent
implementation and some did a volatile implementation.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Hirochika Asai <[email-masked]>
Date: Thu, 29 Aug 2013 17:27:42 +0900

As for the read-write objects, i.e., vmMinCpuNumber, vmMaxCpuNumber,
vmMinMem, and vmMaxMem, I changed the following phrase for the next
version of the draft.

(deleted) Changes to this object may not persist across restarts of the hypervisor
(added) Changes to this object must not persist across restarts of the hypervisor

Thank you.
Hirochika

-- 
Hirochika Asai <[email-masked]>, The University of Tokyo

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 29 Aug 2013 10:02:57 -0400

> >> I really don't like the idea of standards prohibiting potentially
> >> useful functionality.

I would like a better understanding/description of the problems that would
be caused by having persistent values for these objects  in some
implementations and volatile values in other implementations, to justify the
MUST NOT usage.

I would like a better understanding of the benefits that might lead some
implementers to have persistent values in their implementations; what
possible useful functionality could we be prohibiting by making this a MUST
NOT?

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hirochika Asai
> Sent: Thursday, August 29, 2013 4:28 AM
> To: Joe Marcus Clarke
> Cc: [email-masked]
> >> Are you requesting that the normative text state that the values
> >> assigned to these object-types SHOULD NOT or MUST NOT persist across
> >> reboots?
> >>
> >> I really don't like the idea of standards prohibiting potentially
> >> useful functionality.
> >
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 29 Aug 2013 11:09:12 -0400

> possible useful functionality could we be prohibiting by making this a MUST

To me, the intent of this MIB is to not be a way of setting persistent
configuration.  This is to prevent POLA violations where I may be used
to VMware's implementation (for example), and then get astonished when I
find that Xen persists the state of the same object that VMware held
volatile.

If the MIB language was more definitive, then an operator would know
that if one of these objects was implemented read-write the setting
would only apply to the current running state, and there would be no
room for ambiguity.

Joe