[Gen-art] A *new* batch of IETF LC reviews - 2015-05-07

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 10 May 2015 18:06 UTC

Return-Path: <prvs=95723c3a35=pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BB7401A8858 for <gen-art@ietfa.amsl.com>; Sun, 10 May 2015 11:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lJdJZBwLBGUm for <gen-art@ietfa.amsl.com>; Sun, 10 May 2015 11:06:10 -0700 (PDT)
Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu []) by ietfa.amsl.com (Postfix) with ESMTP id 800341A8851 for <gen-art@ietf.org>; Sun, 10 May 2015 11:06:09 -0700 (PDT)
X-AuditID: 12074414-f797f6d000004084-82-554f9e10c382
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU []) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B7.4F.16516.01E9F455; Sun, 10 May 2015 14:06:08 -0400 (EDT)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t4AI67Ev013594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 10 May 2015 14:06:08 -0400
Message-ID: <554F9E0E.9070203@alum.mit.edu>
Date: Sun, 10 May 2015 14:06:06 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: draft-ietf-opsawg-vmm-mib-all@ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixO6iqCswzz/U4OZvaYuzh34xWVx99ZnF gcljyZKfTAGMUdw2SYklZcGZ6Xn6dgncGbcOdrAUzJCsWHD4KEsD42yRLkYODgkBE4klV1W7 GDmBTDGJC/fWs3UxcnEICVxmlFj5eBcThPOcSWL23u+MIFW8AtoShzecZwexWQRUJc4c6GID sdkEtCTmHPrPAmKLCqRIPPz7mxmiXlDi5MwnYHERoJoXaxexgtjMAvoSR/7sZgKxhQUcJFZc vAcVt5W4M3c3M4QtL7H97RzmCYx8s5CMmoWkbBaSsgWMzKsY5RJzSnN1cxMzc4pTk3WLkxPz 8lKLdC30cjNL9FJTSjcxQgJOZAfjkZNyhxgFOBiVeHg3nPQLFWJNLCuuzD3EKMnBpCTKu7Le P1SILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK/ObKAcb0piZVVqUT5MSpqDRUmc99tidT8hgfTE ktTs1NSC1CKYrAwHh5IE7985QI2CRanpqRVpmTklCGkmDk6Q4VxSIsWpeSmpRYmlJRnxoMiL LwbGHkiKB2gvx1yQvcUFiblAUYjWU4yKUuK8N0DmCoAkMkrz4MbC0sgrRnGgL4V57UHaeYAp CK77FdBgJqDBf4t9QAaXJCKkpBoYg3bItbSYah7+oae54k37ypiTZl0p1nUqG2It+nPyOK+l a072sf0m/tDc/VDy5/KNk9c9XVi1iy+pZe9az/MLUkret0SdOvDtyYoe+3XXDB53+vjVLarc KbTh1rJKBsE5MRNmOvpzFDQLazTemjdjsV5G5PS9MzK82iYVSIhP/86/eMpnzt2JSizFGYmG WsxFxYkAi6pOQ/4CAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/jP3MMYQO5EF2Y5gaVUe9x1jO8b4>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: [Gen-art] A *new* batch of IETF LC reviews - 2015-05-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 May 2015 18:06:12 -0000

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.