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

> I think accepting the line of reasoning that "since this MIB is not about
> configuration" that configuration should therefore be *prohibited* would
set
> a very bad precedent.

+1

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On
> Behalf Of Randy Presuhn
> Sent: Thursday, August 29, 2013 1:53 PM
> To: opsawg@ietf.org
> Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on
> draft-asai-vmm-mib-04)
> 
> Hi -
> 
> >From: ietfdbh <ietfdbh@comcast.net>
> >Sent: Aug 29, 2013 7:02 AM
> ...
> >Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re:	Comments
> 	on	draft-asai-vmm-mib-04)
> >
> >> >> I really don't like the idea of standards prohibiting potentially
> >> >> useful functionality.
> ...
> >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?
> 
> As I understand it, the objects vmMinCpuNumber, vmMaxCpuNumber,
> vmMinMem, and vmMaxMem, have a potentially significant impact on the
> capability of both the VM and the performance of the hosting system,
> something that might well be of interest in, for example, an SLA.  As
such, it
> would seem useful to not be required to "forget" the settings.
> 
> I think accepting the line of reasoning that "since this MIB is not about
> configuration" that configuration should therefor be *prohibited* would
set
> a very bad precedent.
> If folks are truly concerned about violating the principle of least
> astonishment, then the correct answer, in my opinion, would be to add a
> StorageType.
> 
> Indeed, if these objects end up being required to *not* persist, then I
could
> well imagine a vendor creating another MIB module to model the data that
> *can* persist.  The semantic relationship between those objects and these
> would almost certainly end up being "astonishing" to operators.
> 
> Randy
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg