Hello, On 2013/10/15, at 23:42, Joe Marcus Clarke <[email protected]> wrote:
> In terms of the new notifications, why enumerate all states as notifications? > My original comment suggested a single state change notification where the > new and previous state would be available as objects (note: this would > require the definition of a previous state object). It just seems like the > way you've implemented it would be harder to scale if new states need to be > added in the future. Ah, I misunderstood your comment. I did the change actually. Consolidating all the notification messages (maybe we will have two eventually, one is for a per VM notification, and the other is for a bulk notification) may be reasonable. # we can even unify a per vm notification and a bulk notification, but maybe it is not a good idea? If there is no strong opinion for not to unify the notification messages, then we will do the change and resubmit an updated version before the cut-off date (next Monday). --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> On 2013/10/15, at 23:42, Joe Marcus Clarke <[email protected]> wrote: > On 10/13/13 11:05 PM, Hirochika Asai wrote: >> Hi folks, >> >> Thanks to comments from the mailing list, we've uploaded new version >> of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >> >> We would like to submit our I-D as a working group draft soon and >> have a discussion in the next IETF as a working group draft. >> Chairs, could you please poll for adoption as a working group item >> on the mailing list? >> >> I've already noticed an error: RFC4133 must be RFC6933. Please let >> us know if you find any other errors. These errors will be >> corrected in the next version (the first version for working group >> draft if adopted). > > Overall, I like the changes. Thanks! > > NIT: VirtualMachineAdminState: > > The destroy(5) state really doesn't match in terms of tense. What about > destroyed(5)? That said, since this is something one can set, perhaps > present tense like run, pause, suspend, etc. make sense. > > Thanks for fleshing out the state definitions :-). > > NIT (maybe a minor issue): VirtualMachineAutoStart: > > Again, tense. Here, I think past tense works best since we decided this > would reflect a read-only state. I think enabled and disabled work best. > > In terms of the new notifications, why enumerate all states as notifications? > My original comment suggested a single state change notification where the > new and previous state would be available as objects (note: this would > require the definition of a previous state object). It just seems like the > way you've implemented it would be harder to scale if new states need to be > added in the future. > > Joe > >> >> >> Here, I summarize the updates from the previous version. >> >> * According to the thread Joe-1 >> Modified a paragraph as follows: >> >> The design of this MIB module has been derived from enterprise >> specific MIB modules, namely a MIB module for managing guests of the >> Xen hypervisor, a MIB module for managing virtual machines controlled >> by the VMware hypervisor, and a MIB module using the libvirt >> programming interface to access different hypervisors. >> + However, this MIB module attempts to generalize >> + the managed objects to support other hypervisors. >> >> * According to the thread Joe-2 >> Added description of an example of hypervisor-specific case >> using ENTITY-MIB, but not modified the MIB definition. >> >> * According to the thread Joe-3 >> vmAutoStart --> read-only >> vmCur* --> read-write >> vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these objects MUST >> NOT persist" >> >> * According to the thread Joe-5 >> For the network portion of the hypervisor, added a note on a case >> equipping virtual switches on the hypervisor as follows: >> The objects related to virtual switches >> are not also included in this MIB module >> though virtual switches shall be placed on a hypervisor. >> This is because the virtual network interfaces are >> the lowest abstraction of network resources allocated >> to a virtual machine. >> Instead of including the objects related to virtual switches, >> for example, <xref target="RFC4188">BRIDGE-MIB</xref> >> and <xref target="RFC4363">Q-BRIDGE-MIB</xref> could be used. >> >> * According to the thread Joe-7 >> Added Notifications for shuttingDown, resuming suspending, migrating, and >> blocked >> # I think we still need discussion at this point. >> >> * Others >> Modified VirtualMachineOperState to be more clear. >> Revised the description of VirtualMachine*Index. >> Fixed some typos. >> >> >> Best regards, >> Hirochika >> >> >> Begin forwarded message: >> >>> From: [email protected] >>> Subject: New Version Notification for draft-asai-vmm-mib-05.txt >>> Date: October 13, 2013 3:19:14 PM GMT+09:00 >>> To: Yuji Sekiya <[email protected]>, Cathy Zhou <[email protected]>, >>> Tina Tsou <[email protected]>, Keiichi Shima >>> <[email protected]>, Juergen Schoenwaelder >>> <[email protected]>, Michael MacFaden <[email protected]>, >>> Hirochika Asai <[email protected]>, Hiroshi Esaki <[email protected]> >>> >>> >>> A new version of I-D, draft-asai-vmm-mib-05.txt >>> has been successfully submitted by Hirochika Asai and posted to the >>> IETF repository. >>> >>> Filename: draft-asai-vmm-mib >>> Revision: 05 >>> Title: Management Information Base for Virtual Machines >>> Controlled by a Hypervisor >>> Creation date: 2013-10-13 >>> Group: Individual Submission >>> Number of pages: 56 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt >>> Status: http://datatracker.ietf.org/doc/draft-asai-vmm-mib >>> Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-asai-vmm-mib-05 >>> >>> Abstract: >>> This document defines a portion of the Management Information Base >>> (MIB) for use with network management protocols in the Internet >>> community. In particular, this specifies objects for managing >>> virtual machines controlled by a hypervisor (a.k.a. virtual machine >>> monitor). >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >> > > > -- > 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
