On 8/29/13 1:53 PM, Randy Presuhn wrote: > 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.
My comments stem from what the draft says in that this MIB is not trying to address config management or persistence to what a vendor may implement. I'm also seeing more users shy away from SNMP for configuration management due to lack of change management hooks (I realize there is an RFC for SNMP and AAA, but I haven't seen wide adoption). Would it not be better to implement something like NETCONF for the configuration side of things if I really wanted to offer configuration? then this MIB could really be left for monitoring. 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 protected] ---------------------------------------------------------------------------- _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
