Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)

Joe Marcus Clarke <jclarke@cisco.com> Thu, 29 August 2013 19:29 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB811E816E for <opsawg@ietfa.amsl.com>; Thu, 29 Aug 2013 12:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.589
X-Spam-Level:
X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLK+ZkbWf79A for <opsawg@ietfa.amsl.com>; Thu, 29 Aug 2013 12:29:39 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F365A11E8167 for <opsawg@ietf.org>; Thu, 29 Aug 2013 12:29:38 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TJTav7029066; Thu, 29 Aug 2013 21:29:37 +0200 (CEST)
Received: from dhcp-10-150-54-22.cisco.com (dhcp-10-150-54-22.cisco.com [10.150.54.22]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TJTa7Z016046; Thu, 29 Aug 2013 15:29:36 -0400 (EDT)
Message-ID: <521FA120.7090401@cisco.com>
Date: Thu, 29 Aug 2013 15:29:36 -0400
From: Joe Marcus Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
In-Reply-To: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 19:29:44 -0000

On 8/29/13 1:53 PM, Randy Presuhn wrote:
> Hi -
> 
>> From: ietfdbh <ietfdbh@comcast.net>
>> Sent: Aug 29, 2013 7:02 AM
> ...
>> Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re:	Comments	on	draft-asai-vmm-mib-04)
>>
>>>>> I really don't like the idea of standards prohibiting potentially
>>>>> useful functionality.
> ...
>> I would like a better understanding of the benefits that might lead some
>> implementers to have persistent values in their implementations; what
>> possible useful functionality could we be prohibiting by making this a MUST
>> NOT?
> 
> As I understand it, the objects vmMinCpuNumber, vmMaxCpuNumber,
> vmMinMem, and vmMaxMem, have a potentially significant impact
> on the capability of both the VM and the performance of the
> hosting system, something that might well be of interest in,
> for example, an SLA.  As such, it would seem useful to not
> be required to "forget" the settings.
> 
> I think accepting the line of reasoning that "since this
> MIB is not about configuration" that configuration should
> therefor be *prohibited* would set a very bad precedent.
> If folks are truly concerned about violating the principle of
> least astonishment, then the correct answer, in my opinion,
> would be to add a StorageType.
> 
> Indeed, if these objects end up being required to *not*
> persist, then I could well imagine a vendor creating another
> MIB module to model the data that *can* persist.  The semantic
> relationship between those objects and these would almost
> certainly end up being "astonishing" to operators.

My comments stem from what the draft says in that this MIB is not trying
to address config management or persistence to what a vendor may
implement.  I'm also seeing more users shy away from SNMP for
configuration management due to lack of change management hooks (I
realize there is an RFC for SNMP and AAA, but I haven't seen wide
adoption).

Would it not be better to implement something like NETCONF for the
configuration side of things if I really wanted to offer configuration?
 then this MIB could really be left for monitoring.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: jclarke@cisco.com

----------------------------------------------------------------------------