Re: [Gen-art] A *new* batch of IETF LC reviews - 2015-05-07
Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 10 May 2015 18:17 UTC
Return-Path: <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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876AE1A88AB for <gen-art@ietfa.amsl.com>; Sun, 10 May 2015 11:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YiJ5ptAWiRl for <gen-art@ietfa.amsl.com>; Sun, 10 May 2015 11:17:16 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280211A88A9 for <gen-art@ietf.org>; Sun, 10 May 2015 11:17:16 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-08v.sys.comcast.net with comcast id SJGw1q00229Cfhx01JHFh9; Sun, 10 May 2015 18:17:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-03v.sys.comcast.net with comcast id SJHF1q0023Ge9ey01JHF0Z; Sun, 10 May 2015 18:17:15 +0000
Message-ID: <554FA0AB.5090201@alum.mit.edu>
Date: Sun, 10 May 2015 14:17:15 -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: gen-art@ietf.org
References: <554F9E0E.9070203@alum.mit.edu>
In-Reply-To: <554F9E0E.9070203@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1431281835; bh=dbKDn5wXF3iJ7BpSEGyokq+nblJVbQmrYU+abRmn6dU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fIzP5DkVfXQMWZhvi5NoC6lH90Fz2YsjAkKAJyIzYNHhGxLaSFngT/q/CpUJ+2km5 mrCx7Kplc4ICKeRCFvpwnECExTSVe9G39SXssQfJnYOPe6PIcJn/UBLETkB2p8iBRj JtajbNMJaMvNgLqrL+RjqPO9QoxDWVQ9na0T0gWFWobxc/aekM+q2sVs2zygxmsvPo 5Srqlt2Bmfax0pFCI5UM7R/JwxOSyjyRjIGV4HOZReqd81TOkbjAZg6+SoQsfmIfoC +os0SOd9t24Z2LvdP9Fom+yVpybX/yWtkCnb+5wbv3/fdwW8/CaQ5/6NPdSur7wtTL 9DI7WpnATLdug==
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/5AIcBc2UhpzRuQRPdnA6Zz70He4>
Subject: Re: [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:17:17 -0000
(sorry - please ignore. I resent with fixed subject and distribution.) On 5/10/15 2:06 PM, Paul Kyzivat 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. > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art >
- [Gen-art] A *new* batch of IETF LC reviews - 2015… A. Jean Mahoney
- [Gen-art] A *new* batch of IETF LC reviews - 2015… Paul Kyzivat
- Re: [Gen-art] A *new* batch of IETF LC reviews - … Paul Kyzivat