Joe, Thank you for your comments.
Yes, 1-8 might lead confusion even though they have the description saying "Changes to this object MUST NOT persist across re-initialization of the hypervisor." If they are no use in practice, changing them to MAX-ACCESS read-only makes things clear. If there are use cases of write access, it can be read-write, but I have currently received no use cases of write access to 1-8. Hirochika On May 27, 2014, at 5:24 AM, Joe Marcus Clarke <[email protected]> wrote: > On 5/26/14, 3:24 AM, Hirochika Asai wrote: >> 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. > > I was vocal against persisting some of these objects, but I think offering > the ability to write to them for running VMs has value (i.e., changes would > not persist), but I can see how that could lead to confusion. If you leave > 1-8 as read-only, that is very clear. > > I think leaving 9 and 10 read-write is fine. > > Joe > >> >> Thank you. >> Hirochika >> > -- Hirochika Asai <[email protected]>, The University of Tokyo _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
