Skip to main content

Last Call Review of draft-ietf-opsawg-vmm-mib-02

Request Review of draft-ietf-opsawg-vmm-mib
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-05-18
Requested 2015-05-07
Authors Hirochika Asai , Michael MacFaden , Jürgen Schönwälder , Keiichi Shima , Tina Tsou (Ting ZOU)
I-D last updated 2015-05-10
Completed reviews Genart Last Call review of -02 by Paul Kyzivat (diff)
Genart Telechat review of -03 by Paul Kyzivat (diff)
Secdir Last Call review of -02 by Christian Huitema (diff)
Opsdir Last Call review of -02 by Dan Romascanu (diff)
Opsdir Telechat review of -03 by Dan Romascanu (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request Last Call review on draft-ietf-opsawg-vmm-mib by General Area Review Team (Gen-ART) Assigned
Reviewed revision 02 (document currently at 04)
Result Ready w/issues
Completed 2015-05-10
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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:


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.