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 (島 慶一) 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 (島 慶一) >> 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
