Hi, I would still recommend that you add text in the Security Considerations section in which you describe the risk of intentional or unintentional misconfiguration of the two writeable objects in the MIB module. It would also be useful to mention explicitly that the authors considered the risks of multiplication of notification and evaluated it as manageable for all reasonably designed and sized networks.
Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, May 26, 2015 9:47 AM > To: Keiichi SHIMA > Cc: Romascanu, Dan (Dan); [email protected]; > [email protected]; [email protected] > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 > > On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: > > Hi all, > > > > >> 17. I am concerned that the current way of defining the > > >> notifications switches is too course. Hypervisors may have many VMs > > >> in charge, and if each generates one notification per each state > > >> changes the numbers can become big even in normal operation. Maybe > > >> some throttling mechanism would be useful. Or maybe a couple of > > >> more switches that allow to enable only 'critical' notifications > > >> (e.g. vmCrashed). > > > > > > The only situation I can think of where the number of notifications > > > will be significant is during restart of a whole rack with many > > > hypervisors inside. But even then, things usually take time. (I > > > think our Xen hypervisors actually create virtual machines > > > sequentially and hence the notifications get actually spaced over > > > time.) It is not unlikely that the operating systems inside the > > > hypervisors during startup generate significantly more network > > > traffic compared to a few hypervisor notifications. That said, > > > during the development of the MIB module we moved from generic > state > > > change notifications to a set of specific notifications and this > > > allows to use SNMPv3 notification filtering to filter out notifications > people find not useful. > > > > > > I and Asai talked locally and we agree Juergen that the number of > notification events is manageable. > > > > However we noticed that the 'vmBlocked' notification may be a problem. > The 'blocked' state is defined as 'The operational state of the virtual > machine > indicating the execution of the virtual machine is currently blocked, e.g., > waiting for some action of the hypervisor to finish. This is a transient > state > from/to other states.' This state transition event may appear more > frequently than other events, since the state is caused by the I/O scheduler > of the hyper visor implementation. > > > > We think we can simply remove the 'vmBlocked' notification. The 'blocked' > state is a transient state and typically return to the previous state > immediately (once the pending I/O requests completed). > > > > Yes, this makes sense to me. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- > 2Duniversity.de_&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=MgxJDgRk1TpLrZ2hiPqtqSLH_gUN > Xo4hIzz7Czjm6c0&s=0FOhbeoR7FEAGZddNHtPDimJFq1MNfZlAEOjldkr1tA&e > = > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
