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 (�u �c一) > 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 (�u �c一) >>> 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
