Re: [eman] Read-Only or Read-Write EMAN MIBs

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 12 February 2014 09:35 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AEE1A08D8 for <eman@ietfa.amsl.com>; Wed, 12 Feb 2014 01:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level:
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham
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 pO-dUsosyrKb for <eman@ietfa.amsl.com>; Wed, 12 Feb 2014 01:35:47 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBAD1A08E9 for <eman@ietf.org>; Wed, 12 Feb 2014 01:35:47 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkIFAARA+1KHCzI1/2dsb2JhbABagmshgQ+/JYEQFnSCJQEBAQEDEig0FwQCAQgNAQMEAQELFAkHMhQJCAIEARIIGodjAZw8rG0XjhE3OAaDHoEUBJ8ZizKDLYIq
X-IronPort-AV: E=Sophos;i="4.95,831,1384318800"; d="scan'208";a="42662934"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Feb 2014 04:35:45 -0500
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 12 Feb 2014 04:22:52 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 10:35:42 +0100
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Thomas Nadeau <tnadeau@lucidvision.com>, eman mailing list <eman@ietf.org>
Thread-Topic: [eman] Read-Only or Read-Write EMAN MIBs
Thread-Index: AQHPJ0LKAi3Xzvo/0kC6ip3cJ++yrZqxWCcg
Date: Wed, 12 Feb 2014 09:35:42 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3FE569@AZ-FFEXMB04.global.avaya.com>
References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com>
In-Reply-To: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions about the Energy Management Working Group <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman/>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 09:35:51 -0000

Hi,

I believe that we need to look carefully what removing writeable objects means at this phase.  

Let us take a look at the writeable objects in draft-ietf-eman-battery-mib-11. There are seven objects with a MAX-ACCESS clause of read-write. 

One of them is batteryChargingAdminState and this is probably the only 'configuration'  object. It does not make too much sense to make it read-only, as there is a corresponding batteryChargingOperState  object. Basically making the MIB module read-only means giving up this functionality and taking out the object. 

The other six objects batteryAlarmLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature set thresholds for notifications. Making the MIB module read-only means that thresholds cannot be set, so there is no use for the objects, and no use for the respective notifications. 

What is the plan? Will the WG renounce to these functions? Is the remaining MIB module consistent enough to be worth making it a standard? If the functionality is still desired do we plan to create a YANG module instead? Will battery devices support NETCONF and YANG? 

Regards,

Dan


 

> -----Original Message-----
> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau
> Sent: Tuesday, February 11, 2014 6:03 PM
> To: eman mailing list
> Subject: [eman] Read-Only or Read-Write EMAN MIBs
> 
> 
> 	EMAN WG:
> 
> 	The EMAN WG currently has three MIBs that are WG drafts:
> 
> 	draft-ietf-eman-battery-mib-11
> 	draft-ietf-eman-energy-aware-mib-14
> 	draft-ietf-eman-energy-monitoring-mib-08
> 
> 	At present Benoit as AD, the Ops Directorate and MIB Doctors are
> preparing a statement to WGs that strongly recommends against MIBs with
> writable objects unless the working group has a strong consensus to do so.
> The current *draft* of the statement is listed here for your information:
> 
> The OPS area recommends the use of NETCONF/YANG standards for
> configuration. IETF working groups are therefore encouraged to use the
> NETCONF/YANG standards for configuration, specifically in new charters.
> SNMP MIB modules modifying persistent configuration state should only be
> produced by working groups in cases of clear utility and overwhelming
> consensus to use SNMP write operations for configuration.
> 
> 	In an effort to head off any potential snafus during the IESG review
> of the three EMAN MIBs, I want to poll the WG for consensus on whether or
> not to make the current list of WG documents read-write or read-only. If
> there is not strong consensus to leave them read-write, Nevil and I will
> instruct the editors to edit the documents to remove writable objects.
> 
> 	Please post comments on this matter by Friday, February 14, 2014 at
> 9AM EDT.
> 
> 
> 	Tom
> 	EMAN WG Co-Chair
> 
>