Hirochika-san, I think this is a good proposal.
Although the 8 objects proposed to be made read-only do not affect persistent hypervisor configuration, they do affect persistent virtual machine configuration (e.g., change of vmAdmin state between running and suspended, as the latter state involves use of "persistent store" for memory and CPU execution state). Making these 8 objects read-only seems reasonable to me. The other two read-write objects control notifications, and I agree with Tom Petch that they should be read-write in the same MIB module as the definitions of the controlled notification: > So the two objects controlling Notifications seem clearly configuration, > whether or not the setting of them persists or is lost on reboot. You > could create a YANG module which controls the setting of these two > objects for SNMP usage but I think that even the IESG might see that > that is an unusual approach, as opposed to making them read-write in > SMI! Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: OPSAWG [mailto:[email protected]] On Behalf Of Hirochika Asai > Sent: Monday, May 26, 2014 3:25 AM > To: [email protected] > Subject: [OPSAWG] Read-write access in VMM-MIB > > Dear all, > > We'd like to discuss the read-write access in the proposed MIB about virtual > machine monitoring: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib . > > It has 10 read-write objects. All of them do not affect persistent > configuration > of hypervisor or virtual machines. However, according to a comment during > the previous IETF meeting, the IESG statement also suggests not to include > read-write objects even if they do not persist after the restart of the agent > or > system. > > In this sense, I think the following 8 objects will be read-only. > 1. vmAdminState > 2. vmCurCpuNumber > 3. vmMinCpuNumber > 4. vmMaxCpuNumber > 5. vmCurMem > 6. vmMinMem > 7. vmMaxMem > 8. vmCpuAffinity > > The following two objects require discussion because these objects are not > related to hypervisor or virtual machines, but notifications of SNMP. > The reason why I think they can be kept read-write is they are control objects > of an SNMP agent and it does not affect the configuration of monitoring > targets. > However, from the viewpoint of security, I can agree that they should also be > read-only and operators configure them not through SNMP (or something) but > through another configuration scheme such as editing a configuration file. > 9. vmPerVMNotificationsEnabled > 10. vmBulkNotificationsEnabled > > I hope you give us your comments on the access of 10 objects. > > Thank you. > Hirochika > > -- > Hirochika Asai <[email protected]>, The University of Tokyo _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
