Tina, Thank you for the response. I updated the draft.
--- Keiichi SHIMA ($)GU5 lcD!) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> On 2013/10/19, at 0:27, Tina TSOU <[email protected]> wrote: > Dear SHIMA-San, > No objection. > > Thank you, > Tina > > On Oct 17, 2013, at 11:34 PM, "Keiichi SHIMA" <[email protected]> wrote: > >> Joe, >> >>> No, TC stays the same, but the tense of the states should change to: >>> >>> unknown(1) >>> enabled(2) >>> disabled(3) >>> >>> Since the associated object is now read-only. >> >> It makes sense. >> >> I'm OK to update the above values. Any objections from other authors? >> >> --- >> Keiichi SHIMA ($)GU5 lcD!) >> WIDE project <[email protected]> >> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> >> >> >> >> On 2013/10/18, at 4:04, Joe Marcus Clarke <[email protected]> wrote: >> >>> On 10/17/13 6:55 AM, Keiichi SHIMA wrote: >>>> Hi, >>>> >>>> On 2013/10/15, at 23:42, Joe Marcus Clarke <[email protected]> wrote: >>>> >>>>> 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. >>>> >>>> The original intention of the naming of VirtualMachineAdminState was, 'to >>>> transit the operation state of a virtual machine to X by setting its admin >>>> state as X'. For example, when we set 'suspended' to the admin state of a >>>> virtual machine, then the virtual machine will start transition to the >>>> suspended operation state. We intentionally used the same state names >>>> here. That is because the tense is past. >>>> >>>> For the 'destroy' admin state, since we didn't have any operation state of >>>> a destroyed virtual machine (that is same as the shutdown operation >>>> state), we didn't pay any attention to the naming. I can live with either >>>> destroy(5) or destroyed(5). It is a matter of taste to me. >>> >>> I think destroy(5) sounds better, but I'll admit it is a nit. >>> >>>> >>>> >>>>> 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. >>>> >>>> Do you mean changing the name to something like >>>> 'VirtualMachineAutoStartEnabled'? Here again, I don't have any strong >>>> opinion on this. I am open to change the name, if most people agree on >>>> this. >>> >>> No, TC stays the same, but the tense of the states should change to: >>> >>> unknown(1) >>> enabled(2) >>> disabled(3) >>> >>> Since the associated object is now read-only. >>> >>> Joe >>> >>>> >>>> Regards, >>>> --- >>>> Keiichi SHIMA ($)GU5 lcD!) >>>> 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 >>>> >>> >>> >>> -- >>> 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
