Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt

[Tina TSOU <[e-mail]>]

Dear SHIMA-San,
No objection.

Thank you,
Tina

On Oct 17, 2013, at 11:34 PM, "Keiichi SHIMA" <[e-mail]> 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 <[e-mail]>
> Research Laboratory, IIJ Innovation Institute, Inc <[e-mail]>
> 
> 
> 
> On 2013/10/18, at 4:04, Joe Marcus Clarke <[e-mail]> wrote:
> 
>> On 10/17/13 6:55 AM, Keiichi SHIMA wrote:
>>> Hi,
>>> 
>>> On 2013/10/15, at 23:42, Joe Marcus Clarke <[e-mail]> 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 <[e-mail]>
>>> Research Laboratory, IIJ Innovation Institute, Inc <[e-mail]>
>>> 
>>> 
>>> 
>>> On 2013/10/15, at 23:42, Joe Marcus Clarke <[e-mail]> 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: [e-mail]
>>>>>> 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 <[e-mail]>, Cathy Zhou <[e-mail]>, Tina Tsou <[e-mail]>, Keiichi Shima <[e-mail]>, Juergen Schoenwaelder <[e-mail]>, Michael MacFaden <[e-mail]>, Hirochika Asai <[e-mail]>, Hiroshi Esaki <[e-mail]>
>>>>>> 
>>>>>> 
>>>>>> 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: [phone]         c i s c o  S y s t e m s
>>>> Email: [e-mail]
>>>> 
>>>> ----------------------------------------------------------------------------
>>>> _______________________________________________
>>>> OPSAWG mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/opsawg
>>> 
>> 
>> 
>> -- 
>> Joe Marcus Clarke, CCIE #5384,         |          |
>> SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
>> Distinguished Services Engineer ..:|||||||||::|||||||||:..
>> Phone: [phone]         c i s c o  S y s t e m s
>> Email: [e-mail]
>> 
>> ----------------------------------------------------------------------------
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg