Yes - this addresses my concern. Thanks and Regards,
Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, May 26, 2015 11:53 AM > To: Romascanu, Dan (Dan) > Cc: Keiichi SHIMA; [email protected]; ops- > [email protected]; [email protected] > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 > > Keiichi, > > note that there is outdated text on page 9 that should be updated: > > The MIB module provides a few writable objects that can be used to > make non-persistent changes, e.g., changing the memory allocation or > the CPU allocation. It is not the goal of this MIB module to provide > a configuration interface for virtual machines since other protocols > and data modeling languages are more suitable for this task. > > In the security considerations, I assume Dan wants: > > OLD > > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have > a MAX-ACCESS clause of read-write. Such objects may be considered > sensitive or vulnerable in some network environments. > > NEW > > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that > have a MAX-ACCESS clause of read-write. Enabling notifications can > lead to a noticeable number of notifications if many virtual > machines change their state concurrently. Hence, such objects may > be considered sensitive or vulnerable in some network environments. > > /js > > On Tue, May 26, 2015 at 07:23:17AM +0000, Romascanu, Dan (Dan) wrote: > > 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 > > > = > > > -- > 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=qQg5JHHnGYDVuGEwHHPY2bhg > mu5R0g- > xo8jGJBsC_nI&s=A7HwS6XPjZEsREWKTr7TANnfo2PZlxIg2bhFUlPeZUw&e= > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
