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

[Randy Presuhn <[e-mail]>]

Hi -

>From: ietfdbh <[e-mail]>
>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