Hi - >From: ietfdbh <[email protected]> >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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
