Dear Paul Kyzivat,
Thank you for your review.
Since the Last call is in process, we do not submit the (current) revised
version but reply with inline comments and the revised version attached in this
mail.
* Figure 2: A few things are fuzzy about this figure:
-- The meaning/purpose of the part above the "====", and its relationship to
the rest of the diagram, isn't clear to me. Is it a legend, explaining the notation for
transient vs. finite states?
My bad. Thank you for your indication. In that figure, we expect to explain
the notation of two types of boxes and a symbol of “!”. So we have modified
the figure to explicitly denote they are the legend.
NEW:
Notation:
+-------------+
| vmOperState | : Finite state; the first line presents the
| | `vmOperState', and the second line presents a
+-------------+ notification generated if applicable.
+ - - - - - - +
| vmOperState | : Transient state; first line presents the
| | `vmOperState', and the second line presents a
+ - - - - - - + notification generated if applicable.
! : Notification; a text followed by the symbol "!"
denotes a notification generated.
=====================================================================
+--------------+ + - - - - - - - + +-------------+
| suspended |<--| suspending | | paused |
| !vmSuspended | | !vmSuspending | | !vmPaused |
+--------------+ + - - - - - - - + +-------------+
| ^ ^
| | |
v | |
+ - - - - - - + +-------------+<----------+ + - - - - - - -+
| resuming |-->| running |<-------------->| migrating |
| !vmResuming | | !vmRunning | | !vmMigrating |
+ - - - - - - + +-------------+ + - - - - - - -+
| ^ ^
| | |
| +-------------------+ |
| | |
v v v
+ - - - - - - - - + +-------------+
| shuttingdown |--------->| shutdown |
| !vmShuttingdown | | !vmShutdown |
+ - - - - - - - - + +-------------+
^ |
| v !vmDeleted
+ - - - - - -+ +------------+ + - - - - - - + (Deleted from
| blocked | | crashed | | preparing | vmTable)
| !vmBlocked | | !vmCrashed | | |
+ - - - - - -+ +------------+ + - - - - - - +
-- what is the point of the 'preparing' state? There is no way in, and the only
way out is to shutdown. (I could understand it as a starting state if there was
a path to running.) While it is described later, in this figure it seems to
have no purpose.
-- the 'blocked' and 'crashed' states have no way either in or out. Surely
there must be some path into these states, and some path out (at least to
shutdown or deleted.)
I see from the later definitions that arbitrary state transitions can be represented. Is
Figure 2 intended to normatively constrain the state transitions? Or does it only provide
an overview of "expected" transitions?
I don't feel I understand the intent sufficiently to suggest changes to remedy
my confusion.
We modified the caption of Figure 2 to denote it is the overview, and added the
explanation that the detailed state transition is summarized in Appendix A.
Although there is no way from/to blocked and crashed as well as one way from
preparing as you pointed out, we consider adding it makes the figure
complicated. Thus, thanks to your suggestion, we changed it to the overview
and promotes readers to refer to Appendix A.
The caption of Figure 2:
OLD:
The state transition of a virtual machine
NEW:
The overview of the state transition of a virtual machine
The paragraph referring to Figure 2:
OLD:
The transition of `vmOperState' by the write access to `vmAdminState' and the
notifications generated by the operational state changes are summarized in
Figure 2.
NEW:
The overview of the transition of `vmOperState' by the write access to
`vmAdminState' and the notifications generated by the operational state changes
are illustrated in Figure 2. The detailed state transition is summarized in
Appendix A.
* Section 5
This says "Hypervisors *shall* implement HOST-RESOURCES-MIB." This sounds
normative. If so, 'shall' should be replaced with MUST.
The MIB module imports HOST-RESOURCES-MIB, so we replace it with MUST.
OLD:
HOST-RESOURCES-MIB defines the MIB objects for managing host systems.
Hypervisors shall implement HOST-RESOURCES-MIB. On systems implementing
HOST-RESOURCES-MIB, the objects of HOST-RESOURCES-MIB indicate resources of a
hypervisor. Some objects of HOST-RESOURCES-MIB shall also be used to indicate
physical resources through indexes.
NEW:
HOST-RESOURCES-MIB defines the MIB objects for managing host systems.
Hypervisors MUST implement HOST-RESOURCES-MIB. On systems implementing
HOST-RESOURCES-MIB, the objects of HOST-RESOURCES-MIB indicate resources of a
hypervisor. Some objects of HOST-RESOURCES-MIB are used to indicate physical
resources through indexes.
The same issue with 'shall' is present in the 2nd paragraph refering to virtual
machines.
Also in the 2nd paragraph I can't parse or fully understand the last sentence. ("This
document defines the objects of these information.") Changing 'these' to 'this' would
make it grammatical, but still not very clear. I guess you mean something like: "This
document defines the relationship between the objects visible to virtual machine operators and
those visible to hypervisor operators.”
We figured that this paragraph was not appropriate to be included here, so removed
it. Note that it explains an operational difference between this document and
HOST-RESOURCES-MIB that may be individually implemented in systems on "virtual
machines”, i.e., guest OS. No need to mention it in this document.
* Section 8 - Security Considerations:
I see no 2119 language in this section, but I see language that sounds normative to me.
E.g., "When SNMPv3 strong security is not used, these objects ***should*** have
access of read-only, not read-write." If these statements are intended to be
normative then please use 2119 language.
We change *should* to *SHOULD* as 2119 language. Also, we capitalize 2119
language in this document.
As for RFC 2119 language, we modified several words to more appropriate ones in
the new version.
The rest leaves me concerned about security. But I will leave it to a security
review to dig into.
Nits/editorial comments:
* The introduction says that this has been derived from "enterprise specific" MIB
modules. But the examples sound more "product-specific" than enterprise-specific. I guess
you mean modules created by the enterprise producing the product, so maybe it is ok, but it struck
me as odd. (Please feel free to leave this as-is if the usage is appropriate in context.)
I agree that the examples except for VMware are product-specific than
enterprise specific.
OLD:
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.
NEW:
The design of this MIB module has been derived from product-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.
* Page 22, DESCRIPTION of vmHvSoftware:
This says "This value should not include its version, and it should be included in
`vmHvVersion'." IIUC 'and' is the wrong word to use here - 'as' would convey the
intended meaning.
Thank you. ‘as’ is what we intended.
Best regards,
Hirochika Asai
On May 11, 2015, at 3:15 AM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-opsawg-vmm-mib-02
Reviewer: Paul Kyzivat
Review Date:
IETF LC End Date: 2015-05-18
IESG Telechat date: (if known)
Summary: Ready with minor issues.
Major issues:
None.
Minor issues:
* Figure 2: A few things are fuzzy about this figure:
-- The meaning/purpose of the part above the "====", and its relationship to
the rest of the diagram, isn't clear to me. Is it a legend, explaining the notation for
transient vs. finite states?
-- what is the point of the 'preparing' state? There is no way in, and the only
way out is to shutdown. (I could understand it as a starting state if there was
a path to running.) While it is described later, in this figure it seems to
have no purpose.
-- the 'blocked' and 'crashed' states have no way either in or out. Surely
there must be some path into these states, and some path out (at least to
shutdown or deleted.)
I see from the later definitions that arbitrary state transitions can be represented. Is
Figure 2 intended to normatively constrain the state transitions? Or does it only provide
an overview of "expected" transitions?
I don't feel I understand the intent sufficiently to suggest changes to remedy
my confusion.
* Section 5
This says "Hypervisors *shall* implement HOST-RESOURCES-MIB." This sounds
normative. If so, 'shall' should be replaced with MUST.
The same issue with 'shall' is present in the 2nd paragraph refering to virtual
machines.
Also in the 2nd paragraph I can't parse or fully understand the last sentence. ("This document
defines the objects of these information.") Changing 'these' to 'this' would make it
grammatical, but still not very clear. I guess you mean something like: "This document defines
the relationship between the objects visible to virtual machine operators and those visible to
hypervisor operators."
* Section 8 - Security Considerations:
I see no 2119 language in this section, but I see language that sounds normative to me.
E.g., "When SNMPv3 strong security is not used, these objects ***should*** have
access of read-only, not read-write." If these statements are intended to be
normative then please use 2119 language.
The rest leaves me concerned about security. But I will leave it to a security
review to dig into.
Nits/editorial comments:
* The introduction says that this has been derived from "enterprise specific" MIB
modules. But the examples sound more "product-specific" than enterprise-specific. I guess
you mean modules created by the enterprise producing the product, so maybe it is ok, but it struck
me as odd. (Please feel free to leave this as-is if the usage is appropriate in context.)
* Page 22, DESCRIPTION of vmHvSoftware:
This says "This value should not include its version, and it should be included in
`vmHvVersion'." IIUC 'and' is the wrong word to use here - 'as' would convey the
intended meaning.
