> 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 [email protected] +1-603-828-1401 > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Randy Presuhn > Sent: Thursday, August 29, 2013 1:53 PM > To: [email protected] > Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on > draft-asai-vmm-mib-04) > > 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
