From bclaise@cisco.com Sun Jan 5 13:58:32 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F3F1AD190; Sun, 5 Jan 2014 13:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 AET2tWwVjVR9; Sun, 5 Jan 2014 13:58:31 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0336D1AD10A; Sun, 5 Jan 2014 13:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4552; q=dns/txt; s=iport; t=1388959103; x=1390168703; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=2l9QXsN6mB2F7DxcrnR+b2tDGlrvurAA2N4ccaWKKi4=; b=EfndWk/Q2zOgQ/LYF376G99cU4wtIvLEfAhc8zWD6eH238eMKmfadeni zdmfegSfeyeyE0vtx370thGME2yitJBh/rach3idBGFMsHFM3d/O14sGR yyRCxfZmBIKR+OVYW/bJ7WUkq/vceRHfhIQmd+yaVVoA6acXDrppyRjEC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIvUyVKQ/khN/2dsb2JhbABYgws4g1O2MoENFnSCJgEBBCMVQBEdCAIFFgsCAgkDAgECATcECgYBDAYCAQEWh2oNqh6ZHxeBKY1tgm+BSASUNAWDXoEwhRWLUIMuO4EuJA X-IronPort-AV: E=Sophos;i="4.95,609,1384300800"; d="scan'208";a="3212054" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 05 Jan 2014 21:58:21 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s05LwKB0030927; Sun, 5 Jan 2014 21:58:20 GMT Message-ID: <52C9D57C.6020505@cisco.com> Date: Sun, 05 Jan 2014 22:58:20 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20140103001959.10097.81832.idtracker@ietfa.amsl.com> In-Reply-To: <20140103001959.10097.81832.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140103001959.10097.81832.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: PRELIMINARY Agenda and Package for the January 9, 2014 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 21:58:32 -0000 Dear all, Please find below the agenda of the Jan 9th IESG telechat. Please send your questions, comments and concerns before Jan 8th COB. Thanks and Regards, Benoit. INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2014-01-09 IESG Teleconference This agenda was generated at 2014-01-02 16:18:37 PST Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-savi-send-10 - IETF stream SEND-based Source-Address Validation Implementation (Proposed Standard) Note: The Document Shepherd is Jean-Michel Combes (jeanmichel.combes at gmail.com). Token: Ted Lemon IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-netmod-iana-if-type-09 - IETF stream IANA Interface Type YANG Module (Proposed Standard) Note: David Kessens (david.kessens@nsn.com) is the document shepherd. Token: Benoit Claise IANA Review: IANA - Not OK Consensus: Yes o draft-ietf-idr-extcomm-iana-02 - IETF stream IANA Registries for BGP Extended Communities (Proposed Standard) Token: Stewart Bryant IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-pwe3-dynamic-ms-pw-20 - IETF stream Dynamic Placement of Multi-Segment Pseudowires (Proposed Standard) Token: Stewart Bryant IANA Review: IANA - Not OK Consensus: Yes o draft-ietf-trill-rfc6327bis-02 - IETF stream TRILL: Adjacency (Proposed Standard) Token: Ted Lemon IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-avtcore-leap-second-07 - IETF stream RTP and Leap Seconds (Proposed Standard) Token: Richard Barnes IANA Review: IANA OK - No Actions Needed Consensus: Unknown o draft-ietf-trill-o-pw-04 - IETF stream Transport of TRILL Using Pseudowires (Proposed Standard) Token: Ted Lemon IANA Review: Version Changed - Review Needed Consensus: Unknown 2.1.2 Returning Items o draft-ietf-pim-explicit-tracking-09 - IETF stream IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers (Proposed Standard) Token: Adrian Farrel IANA Review: IANA OK - No Actions Needed Consensus: Yes 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items o draft-moonesamy-ietf-conduct-3184bis-05 - IETF stream IETF Guidelines for Conduct (Best Current Practice) Token: Jari Arkko IANA Review: IANA OK - No Actions Needed Consensus: Unknown Was deferred by Pete Resnick on 2013-12-19 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-isis-rfc1142-to-historic-00 - IETF stream Reclassification of RFC 1142 to Historic (Informational) Token: Adrian Farrel IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-clue-telepresence-use-cases-08 - IETF stream Use Cases for Telepresence Multi-streams (Informational) Token: Gonzalo Camarillo IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-siprec-architecture-11 - IETF stream An Architecture for Media Recording using the Session Initiation Protocol (Informational) Token: Gonzalo Camarillo IANA Review: Version Changed - Review Needed Consensus: Yes o draft-ietf-ospf-manet-single-hop-or-04 - IETF stream Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks (Experimental) Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Unknown 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 7. Working Group News From adrian@olddog.co.uk Sat Jan 11 11:59:14 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B497E1AE072 for ; Sat, 11 Jan 2014 11:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 ZAaafPYSJWjq for ; Sat, 11 Jan 2014 11:59:13 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 396A51AE06D for ; Sat, 11 Jan 2014 11:59:13 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0BJw5nO030077; Sat, 11 Jan 2014 19:58:05 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0BJw2oV030060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jan 2014 19:58:03 GMT From: "Adrian Farrel" To: , Date: Sat, 11 Jan 2014 19:57:59 -0000 Message-ID: <006601cf0f07$7148ae10$53da0a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8PB2qbyfGKQaL5SGCuAHTamSByuA== Content-Language: en-gb Cc: kkoushik@cisco.com, 'Daniel King' , 'JP Vasseur' , emile.stephan@orange.com, 'Jonathan Hardwick' , 'Quintin zhao' , Julien Meuric Subject: [MIB-DOCTORS] Request for MIB Dr Review for draft-ietf-pce-pcep-mib-06 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 19:59:14 -0000 Hi MIB Doctors and ADs, This draft is coming close to working group last call and the authors and chairs of the PCE WG would appreciate a MIB Doctor review. Could you make that happen or let us know that no-one is currently available. Thanks, Adrian From j.schoenwaelder@jacobs-university.de Sat Jan 11 12:20:09 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4944C1AE084 for ; Sat, 11 Jan 2014 12:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 lDyzqhsJDzai for ; Sat, 11 Jan 2014 12:20:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AE6251AE0F8 for ; Sat, 11 Jan 2014 12:20:06 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC0E920091; Sat, 11 Jan 2014 21:19:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30dHpymH8HQT; Sat, 11 Jan 2014 21:19:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E6F420090; Sat, 11 Jan 2014 21:19:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 27FA62A848FA; Sat, 11 Jan 2014 21:19:51 +0100 (CET) Date: Sat, 11 Jan 2014 21:19:51 +0100 From: Juergen Schoenwaelder To: Adrian Farrel Message-ID: <20140111201951.GA51776@elstar.local> Mail-Followup-To: Adrian Farrel , mib-doctors@ietf.org, ops-ads@tools.ietf.org, kkoushik@cisco.com, 'Daniel King' , 'JP Vasseur' , emile.stephan@orange.com, 'Jonathan Hardwick' , 'Quintin zhao' , Julien Meuric References: <006601cf0f07$7148ae10$53da0a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006601cf0f07$7148ae10$53da0a30$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kkoushik@cisco.com, 'Daniel King' , mib-doctors@ietf.org, ops-ads@tools.ietf.org, 'JP Vasseur' , emile.stephan@orange.com, 'Jonathan Hardwick' , 'Quintin zhao' , Julien Meuric Subject: Re: [MIB-DOCTORS] Request for MIB Dr Review for draft-ietf-pce-pcep-mib-06 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 20:20:09 -0000 On Sat, Jan 11, 2014 at 07:57:59PM +0000, Adrian Farrel wrote: > Hi MIB Doctors and ADs, > > This draft is coming close to working group last call and the authors and chairs > of the PCE WG would appreciate a MIB Doctor review. > > Could you make that happen or let us know that no-one is currently available. > I could take a look at it. When do you need a review? I might find time next week or the last week in January. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From adrian@olddog.co.uk Sun Jan 12 03:47:22 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152311AE018 for ; Sun, 12 Jan 2014 03:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Yr30m2vDvjqU for ; Sun, 12 Jan 2014 03:47:19 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id DA4A01AE024 for ; Sun, 12 Jan 2014 03:47:18 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0CBkghY022676; Sun, 12 Jan 2014 11:46:44 GMT Received: from 950129200 (213-239.197-178.cust.bluewin.ch [178.197.239.213]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0CBkeQk022666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Jan 2014 11:46:41 GMT From: "Adrian Farrel" To: "'Juergen Schoenwaelder'" References: <006601cf0f07$7148ae10$53da0a30$@olddog.co.uk> <20140111201951.GA51776@elstar.local> In-Reply-To: <20140111201951.GA51776@elstar.local> Date: Sun, 12 Jan 2014 11:46:41 -0000 Message-ID: <00dd01cf0f8b$f6bc4c80$e434e580$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGUYuzt6QNsjUF0PqyBEDw3ay53NQK4t0MKmuCMLNA= Content-Language: en-gb X-TM-AS-MML: No Cc: kkoushik@cisco.com, 'Daniel King' , mib-doctors@ietf.org, ops-ads@tools.ietf.org, 'JP Vasseur' , emile.stephan@orange.com, 'Jonathan Hardwick' , 'Quintin zhao' , 'Julien Meuric' Subject: Re: [MIB-DOCTORS] Request for MIB Dr Review for draft-ietf-pce-pcep-mib-06 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 11:47:22 -0000 Hi Juergen, Great! Any review is good review and I think that if the chairs know your schedule they will embrace it. A > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 11 January 2014 20:20 > To: Adrian Farrel > Cc: mib-doctors@ietf.org; ops-ads@tools.ietf.org; kkoushik@cisco.com; 'Daniel > King'; 'JP Vasseur'; emile.stephan@orange.com; 'Jonathan Hardwick'; 'Quintin > zhao'; Julien Meuric > Subject: Re: [MIB-DOCTORS] Request for MIB Dr Review for draft-ietf-pce-pcep- > mib-06 > > On Sat, Jan 11, 2014 at 07:57:59PM +0000, Adrian Farrel wrote: > > Hi MIB Doctors and ADs, > > > > This draft is coming close to working group last call and the authors and chairs > > of the PCE WG would appreciate a MIB Doctor review. > > > > Could you make that happen or let us know that no-one is currently available. > > > > I could take a look at it. When do you need a review? I might find > time next week or the last week in January. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From bclaise@cisco.com Mon Jan 13 05:21:29 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370651AE169 for ; Mon, 13 Jan 2014 05:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 do1dYQEeXkyH for ; Mon, 13 Jan 2014 05:21:28 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id A09FA1ADFA2 for ; Mon, 13 Jan 2014 05:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=626; q=dns/txt; s=iport; t=1389619277; x=1390828877; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=e57/EaV8e4tgRjkncm8Jj6S6+ePm/zkNW+ZrzOILkG0=; b=MFhsQrbeFBmN/JU0hgcdFHPZFc0XC8zgX0L9uH2RzJhv9D5nVQVsJX9q yYvK1eZMCG+QqqPXY4/8o0Cp4KzknpYy8nZjYveGyPP3rvQlmKG+8ej7U DxW1432DNU3JHBnuJuMVoNBGGPvmhdWvm6aCJDSXtLIlzHyZTBXGClVnb 4=; X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208";a="2893122" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 13 Jan 2014 13:21:16 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0DDLFd5017180; Mon, 13 Jan 2014 13:21:15 GMT Message-ID: <52D3E847.9000907@cisco.com> Date: Mon, 13 Jan 2014 14:21:11 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Farrel , mib-doctors@ietf.org, ops-ads@tools.ietf.org, kkoushik@cisco.com, "'Daniel King'" , "'JP Vasseur'" , emile.stephan@orange.com, "'Jonathan Hardwick'" , "'Quintin zhao'" , Julien Meuric References: <006601cf0f07$7148ae10$53da0a30$@olddog.co.uk> <20140111201951.GA51776@elstar.local> In-Reply-To: <20140111201951.GA51776@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MIB-DOCTORS] Request for MIB Dr Review for draft-ietf-pce-pcep-mib-06 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:21:29 -0000 Thanks Jürgen for stepping forward; The http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history web page has been updated. Regards, Benoit > On Sat, Jan 11, 2014 at 07:57:59PM +0000, Adrian Farrel wrote: >> Hi MIB Doctors and ADs, >> >> This draft is coming close to working group last call and the authors and chairs >> of the PCE WG would appreciate a MIB Doctor review. >> >> Could you make that happen or let us know that no-one is currently available. >> > I could take a look at it. When do you need a review? I might find > time next week or the last week in January. > > /js > From tnadeau@lucidvision.com Mon Jan 13 07:12:51 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097CA1AE1D5; Mon, 13 Jan 2014 07:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 BY15kfXGai_u; Mon, 13 Jan 2014 07:12:49 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BEDD61AE1E1; Mon, 13 Jan 2014 07:12:40 -0800 (PST) Received: from [192.168.1.115] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8CB6D26B2F85; Mon, 13 Jan 2014 10:12:29 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Mon, 13 Jan 2014 10:12:28 -0500 Message-Id: <6EA2D6B2-EB15-4DDE-8128-81ED97BB05B1@lucidvision.com> References: <18241430.1388083851066.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> To: "MIB Doctors (E-mail)" , eman mailing list X-Mailer: Apple Mail (2.1827) Subject: [MIB-DOCTORS] A single OID versus multiple OIDs for EMAN MIBs X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:12:51 -0000 --Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Speaking as a MIB Doctor and EMAN co-chair, I want to call = consensus so that we could close on this issue and so that the MIBs in = question can be progressed as well as give direct to any future EMAN = MIBs. The consensus was that we would use the recommendations from = RFC2578 instead of falling under a single "eman MIB root" OID. To this = end, I am directing the various MIB editors to please restructure their = OID assignments accordingly by rooting under the IANA management tree. =20= This is the relevant text from RFC 4181 section 4.5 for = reference. The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past, some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. Thanks, --Tom --Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS1AJcAAoJEPcO+I7eiUJZz+cP/RwAitCdKecELyRHIsCnlPwX hRb8DoVfVTMfhpIV/9mVmkKS8x/aINogcWYmvKnpoomrH5AOm6T/5Uz+TUqO+v9l noSQAiCPtt/L2794+C0YWmGwWvfZBblvJSvmsdJ4A9C/uIDQ++Woxjfln2Efo2NW BI+POwOqZ6JG60SZNXhbUIFJlSgR4YmoyunqS1A0/H8Z1Iv8LbetqyKiEeh4H7Pn HTLSD+fg+fqhV5MfoeEgssv8lKgFSWJyCbb3PK2trYspKvCn1amETxGHkyMzLoGL ktpWtv1l0zvwUldu/6MkX6jgW/Js3jpp4XqGj19kzZzk4UXPyStpZ7m5juyc915o BxQ5M6pEK/JyJur/HQ+n1zSbjHYrx404GY5Ee/ptWedFVXerJmOe+Kspt7R70lAC gaLHpvTBQX55SPeJPjV74KNUiXC/Yv1hYtcJ6HfY+vqFDmDZ37wrBqBS3fKypOk2 KvEtBb5fj5TOl+pqzCDYgU7NDr6boMEI5bLPnaUL/DeVhyBdencbmmMCWpCI8isA 8tPpa3DNEABB1vrY9t6GMl/SCzhGs/oY2W9XUj2Y5pm9emYqAzD/Ia3QUd6Gqh46 QLnF3xGR5IF1C3xctNJADR0IE3WX/22fd612zvsbmhfOutUxtTlggfkx+9I2qzJl BWNnmIOGD9LKAoJHuE9p =PwU5 -----END PGP SIGNATURE----- --Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28-- From bclaise@cisco.com Tue Jan 14 09:26:28 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BBE1AE149 for ; Tue, 14 Jan 2014 09:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 CxeCNau727U0 for ; Tue, 14 Jan 2014 09:26:26 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DF1AE164 for ; Tue, 14 Jan 2014 09:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=891; q=dns/txt; s=iport; t=1389720374; x=1390929974; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Mfh5VV1JcAdn9UW8Jg3owhCT+Y0HdQLrW2akSqHIRyY=; b=W/c/4AvBLc0K7+hU51zSOpWVgML97hovGp0LkQGDqgETnCxdHJNdWy+j ISmwCqYP3cBfpRW55YjTmm+Md8HwQz1arvf7ChrqVUczQqn7WGRhOESDe xTBu1mOahItNV8y97jvcBdI3iYaJjA56zm3p6cg6d+HUgIiaA4x/b8gF2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcIAG9y1VKQ/khL/2dsb2JhbABagws4tAqHKIEVFnSCJQEBAQMBAQEBNTYLBQsLISUPAhYwBwwBBQIBAQWHcwgNw3gXjwcHhDcBA5gegTCFFYtQgy47 X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="2951574" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 14 Jan 2014 17:26:13 +0000 Received: from [10.149.0.203] (dhcp-10-149-0-203.cisco.com [10.149.0.203]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0EHQDT5000519; Tue, 14 Jan 2014 17:26:13 GMT Message-ID: <52D57335.40205@cisco.com> Date: Tue, 14 Jan 2014 18:26:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, ops-ads@tools.ietf.org, mib-doctors@ietf.org References: <066d01cf0416$bccb85c0$36629140$@olddog.co.uk> In-Reply-To: <066d01cf0416$bccb85c0$36629140$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfd-chairs@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:26:28 -0000 Dear MIB doctors, Who would like to volunteer? A simple comparison between the MIB doctors list (http://www.ietf.org/iesg/directorate/mib-doctors.html) and the latest assignments (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history) would guide me in kindly requesting the next volunteers. However, it's always better if you volunteer yourself :-) Regards, Benoit > Hi, > > Heads up that two documents are in the pipe. > > https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ > https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ > > I shall be reviewing them as AD in the next couple of days and then expect to > issue IETF last call. > > Thanks for the work. > > Adrian > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From bertietf@bwijnen.net Tue Jan 14 09:42:10 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355D91AE125 for ; Tue, 14 Jan 2014 09:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YNKHD7TfEZLW for ; Tue, 14 Jan 2014 09:42:08 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 146B71AE124 for ; Tue, 14 Jan 2014 09:42:07 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W37zt-0003ip-UJ; Tue, 14 Jan 2014 18:41:55 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W37zt-0001tM-Q7; Tue, 14 Jan 2014 18:41:53 +0100 Message-ID: <52D576E1.9060600@bwijnen.net> Date: Tue, 14 Jan 2014 18:41:53 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Benoit Claise , adrian@olddog.co.uk, ops-ads@tools.ietf.org, mib-doctors@ietf.org References: <066d01cf0416$bccb85c0$36629140$@olddog.co.uk> <52D57335.40205@cisco.com> In-Reply-To: <52D57335.40205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47da96caefbdd8753b80b4d4d4047f716 Cc: bfd-chairs@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:42:10 -0000 I can do these in the next week or so. Bert On 14/01/14 18:26, Benoit Claise wrote: > Dear MIB doctors, > > Who would like to volunteer? > A simple comparison between the MIB doctors list (http://www.ietf.org/iesg/directorate/mib-doctors.html) and the latest assignments > (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history) would guide me in kindly requesting the next volunteers. > However, it's always better if you volunteer yourself :-) > > Regards, Benoit > >> Hi, >> >> Heads up that two documents are in the pipe. >> >> https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ >> https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ >> >> I shall be reviewing them as AD in the next couple of days and then expect to >> issue IETF last call. >> >> Thanks for the work. >> >> Adrian >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From bclaise@cisco.com Tue Jan 14 13:44:18 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7A41AE008 for ; Tue, 14 Jan 2014 13:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Eq3dksBPWkH0 for ; Tue, 14 Jan 2014 13:44:17 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id EE4E11ADF99 for ; Tue, 14 Jan 2014 13:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1376; q=dns/txt; s=iport; t=1389735846; x=1390945446; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PDVpbV0bCulOFdUUGeKvEbk9YmlwuZEafnx0t5h0yHg=; b=nLY3O4Rqm/YY8XzMhLUkynquF1GW/IBReRHkFBviWw4wwTdWW6i/1OR6 0eXTRbqrrm/dxV0ZCip3wpOE7SpON+T4p4fa1JgEFDTenaNOB0WIlvYJF ajAOHVnfJ6ZGqZrHs/Ry4xJ6enCFN1+in3BITMfWRlR3qjcqeVUtnKCBh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcIAGiu1VKQ/khR/2dsb2JhbABagws4tBqHKIEYFnSCJQEBAQQBAQE1NgsQCxgJJQ8CFjAGAQwBBQIBAQWHew3DdhePBweENwEDmB6BMIUVi1CDLjs X-IronPort-AV: E=Sophos;i="4.95,659,1384300800"; d="scan'208";a="2957732" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 14 Jan 2014 21:44:03 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0ELi13k017040; Tue, 14 Jan 2014 21:44:01 GMT Message-ID: <52D5AFA1.50301@cisco.com> Date: Tue, 14 Jan 2014 22:44:01 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , adrian@olddog.co.uk, ops-ads@tools.ietf.org, mib-doctors@ietf.org References: <066d01cf0416$bccb85c0$36629140$@olddog.co.uk> <52D57335.40205@cisco.com> <52D576E1.9060600@bwijnen.net> In-Reply-To: <52D576E1.9060600@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfd-chairs@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:44:18 -0000 Many thanks Bert, http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history has been updated. Regards, Benoit > I can do these in the next week or so. > > Bert > > On 14/01/14 18:26, Benoit Claise wrote: >> Dear MIB doctors, >> >> Who would like to volunteer? >> A simple comparison between the MIB doctors list >> (http://www.ietf.org/iesg/directorate/mib-doctors.html) and the >> latest assignments >> (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history) >> would guide me in kindly requesting the next volunteers. >> However, it's always better if you volunteer yourself :-) >> >> Regards, Benoit >> >>> Hi, >>> >>> Heads up that two documents are in the pipe. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ >>> >>> I shall be reviewing them as AD in the next couple of days and then >>> expect to >>> issue IETF last call. >>> >>> Thanks for the work. >>> >>> Adrian >>> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > . > From nobo@cisco.com Tue Jan 14 10:43:07 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142FE1AE230 for ; Tue, 14 Jan 2014 10:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 fZTk1Z3C8xfm for ; Tue, 14 Jan 2014 10:43:05 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8B1AE1E6 for ; Tue, 14 Jan 2014 10:43:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1850; q=dns/txt; s=iport; t=1389724974; x=1390934574; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nlEy0KN4veVHZRZ12Dx2KfJNmqq9XKyQsLcL5Nq6wpE=; b=APiajE1PrhjNCUaQmcDnL1BfOK+aCs9X5aO0tnSPBqg8Ts68R3DriK/q +euCXSuwdbSsxuyAj0xND+ezvV/1V+QrbEMCPQ/q1/RFbquQUx39OQvvM Ep9W8b8KerPwdRWLsOYQGqMT1S/n6QZtjUikHRSKJ6BlLqnKSpLiwYrJM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwIAFGE1VKtJXHB/2dsb2JhbABagmohOFazNocogRUWdIIlAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQBDQUIAYd7AQzEKBeOVjECBQaDHoETBJlOkGWDLYIq X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="297299562" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jan 2014 18:42:53 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0EIgrYP029292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 18:42:53 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 12:42:53 -0600 From: "Nobo Akiya (nobo)" To: "Bert Wijnen (IETF)" , "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" , "ops-ads@tools.ietf.org" , "mib-doctors@ietf.org" Thread-Topic: [MIB-DOCTORS] Heads up MIB documents in the pipe Thread-Index: Ac8EFodnu/loc1NJQN+B1mVgzNzUVwNaXwmAAACMEoAACqigUA== Date: Tue, 14 Jan 2014 18:42:52 +0000 Message-ID: References: <066d01cf0416$bccb85c0$36629140$@olddog.co.uk> <52D57335.40205@cisco.com> <52D576E1.9060600@bwijnen.net> In-Reply-To: <52D576E1.9060600@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 14 Jan 2014 13:45:13 -0800 Cc: "Zafar Ali \(zali\)" , "bfd-chairs@tools.ietf.org" Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:43:07 -0000 Hi, Thank you Bert. There were number of comments provided from Adrian. It'll b= e beneficial to address those before MIB doctor pass through. Tom/Zafar, ca= n you notify Bert when pending comments have been addressed? Thanks, Nobo > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: Tuesday, January 14, 2014 12:42 PM > To: Benoit Claise (bclaise); adrian@olddog.co.uk; ops-ads@tools.ietf.org; > mib-doctors@ietf.org > Cc: bfd-chairs@tools.ietf.org > Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe >=20 > I can do these in the next week or so. >=20 > Bert >=20 > On 14/01/14 18:26, Benoit Claise wrote: > > Dear MIB doctors, > > > > Who would like to volunteer? > > A simple comparison between the MIB doctors list > > (http://www.ietf.org/iesg/directorate/mib-doctors.html) and the latest > > assignments > > (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-histo= ry) > would guide me in kindly requesting the next volunteers. > > However, it's always better if you volunteer yourself :-) > > > > Regards, Benoit > > > >> Hi, > >> > >> Heads up that two documents are in the pipe. > >> > >> https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ > >> https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ > >> > >> I shall be reviewing them as AD in the next couple of days and then > >> expect to issue IETF last call. > >> > >> Thanks for the work. > >> > >> Adrian > >> > >> _______________________________________________ > >> MIB-DOCTORS mailing list > >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mib-doctors > >> > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > From bclaise@cisco.com Wed Jan 15 01:10:46 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3511AE2E1 for ; Wed, 15 Jan 2014 01:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 fg1GFGs7k7WE for ; Wed, 15 Jan 2014 01:10:43 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5779B1AE02E for ; Wed, 15 Jan 2014 01:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=416; q=dns/txt; s=iport; t=1389777032; x=1390986632; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Xa97CJhwpVhYKMUUTZHPEBPuiw6YUAlAiQwp77FUvT4=; b=MRlDinvMoZUL7CAnv4nmfRymbExmFNGXb9A1d/polLgxB+X4WzMtNVsh g1qqY7hBTLtDxCnDr4TLtofayiX2cUKjdSYcXiKNoJnFLhLOo/pqjVeyI DfMD/Kh7zm4ZERhufMa8WcHkHZdm21ZFPXo96Gz0XfgTYTf6gojjcmwn4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUHABxQ1lKQ/khR/2dsb2JhbABagws4tCqIPBZ0gmRAPRYYAwIBAgFLDQgBAYgADZhvqwcXk0UBA5gegTCFFYtQgy47 X-IronPort-AV: E=Sophos;i="4.95,661,1384300800"; d="scan'208";a="3648714" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 15 Jan 2014 09:10:31 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0F9AUJp009870 for ; Wed, 15 Jan 2014 09:10:31 GMT Message-ID: <52D65086.2030302@cisco.com> Date: Wed, 15 Jan 2014 10:10:30 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] MIB doctor web site: "ongoing" status X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 09:10:46 -0000 Dear all, It was mentioned to me that the "ongoing" status at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history was not specific enough. For example, it was not clear what the next action is, and who is responsible for it. I tried to improve this status based on my knowledge. Let me know if this is correct. Note: I don't plan to micro manage those status. Regards, Benoit From dromasca@avaya.com Wed Jan 15 01:32:27 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062BB1AE032 for ; Wed, 15 Jan 2014 01:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 gQhst-2_SIFb for ; Wed, 15 Jan 2014 01:32:25 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 54EDD1AE02E for ; Wed, 15 Jan 2014 01:32:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0HAFxU1lKHCzI1/2dsb2JhbABagmohOFazVIcogRQWdIIlAQEBAQMBAQEPXBcEAgEGAg0BAwQBAQsdBycLFAkIAgQBEggah2IBDIwSkTCmOBeOVjgGgx6BEwSZToU8iymDLYIq X-IronPort-AV: E=Sophos;i="4.95,661,1384318800"; d="scan'208";a="45031627" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jan 2014 04:32:12 -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; 15 Jan 2014 04:20:19 -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.0158.001; Wed, 15 Jan 2014 10:32:11 +0100 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "MIB Doctors (E-mail)" Thread-Topic: [MIB-DOCTORS] MIB doctor web site: "ongoing" status Thread-Index: AQHPEdGpO2agYAvvnkyRsvcs1W9+VJqFhSqA Date: Wed, 15 Jan 2014 09:32:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243CE6C1@AZ-FFEXMB04.global.avaya.com> References: <52D65086.2030302@cisco.com> In-Reply-To: <52D65086.2030302@cisco.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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MIB-DOCTORS] MIB doctor web site: "ongoing" status X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 09:32:27 -0000 Hi, I would maybe be useful if each of us would edit the entries for the items = that were assigned to us.=20 Regards, Dan > -----Original Message----- > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of > Benoit Claise > Sent: =E9=E5=ED=A0=E3 15 =E9=F0=E5=E0=F8 2014 11:11 > To: MIB Doctors (E-mail) > Subject: [MIB-DOCTORS] MIB doctor web site: "ongoing" status >=20 > Dear all, >=20 > It was mentioned to me that the "ongoing" status at > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history > was not specific enough. > For example, it was not clear what the next action is, and who is respons= ible > for it. >=20 > I tried to improve this status based on my knowledge. > Let me know if this is correct. > Note: I don't plan to micro manage those status. >=20 > Regards, Benoit >=20 >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Wed Jan 15 01:49:54 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D51ADF88 for ; Wed, 15 Jan 2014 01:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 62XkhKJvEj0U for ; Wed, 15 Jan 2014 01:49:53 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id D40711ADBD1 for ; Wed, 15 Jan 2014 01:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1167; q=dns/txt; s=iport; t=1389779381; x=1390988981; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=I/6syUT1X5Z6vBh+09Y9oqmNw4SMoIkcRqN+Gl/57dE=; b=PaWNRRhz17IWyRGUDVCdtEACQbD6QWYew0QzmJfe5OdI9KWq6XsRiF+x PzX5XnV8mijlfQ1wu1ETmCrA6l9BVU8USZlQfNgBaxgNmFySilrv5zN6u AHQ2ahfpV5VsynOciEQkj/mGw4O//NQDFQE8hEvdlQAIDdnRQXPp1pV3T c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsHAIBZ1lKQ/khN/2dsb2JhbABagws4tCqHKIEVFnSCJQEBAQQBAQEvAQU2Cg0ECQIRBAEBAQkWCAcJAwIBAgEVHwkIBgEMBgIBAYgADYwRt2gXjw4GhDEBA5gegTCFFYtQgy47 X-IronPort-AV: E=Sophos;i="4.95,661,1384300800"; d="scan'208";a="3650699" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 15 Jan 2014 09:49:30 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0F9nUfN022287; Wed, 15 Jan 2014 09:49:30 GMT Message-ID: <52D659A9.7020205@cisco.com> Date: Wed, 15 Jan 2014 10:49:29 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , "MIB Doctors (E-mail)" References: <52D65086.2030302@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA243CE6C1@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243CE6C1@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MIB-DOCTORS] MIB doctor web site: "ongoing" status X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 09:49:54 -0000 On 15/01/2014 10:32, Romascanu, Dan (Dan) wrote: > Hi, > > I would maybe be useful if each of us would edit the entries for the items that were assigned to us. That would be ideal indeed. Feel free to update the WIKI as you wish. Regards, Benoit > > Regards, > > Dan > > >> -----Original Message----- >> From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of >> Benoit Claise >> Sent: éåí ã 15 éðåàø 2014 11:11 >> To: MIB Doctors (E-mail) >> Subject: [MIB-DOCTORS] MIB doctor web site: "ongoing" status >> >> Dear all, >> >> It was mentioned to me that the "ongoing" status at >> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history >> was not specific enough. >> For example, it was not clear what the next action is, and who is responsible >> for it. >> >> I tried to improve this status based on my knowledge. >> Let me know if this is correct. >> Note: I don't plan to micro manage those status. >> >> Regards, Benoit >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > . > From bclaise@cisco.com Fri Jan 17 00:01:17 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5861ADFB5; Fri, 17 Jan 2014 00:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Ave9nGB-BSsn; Fri, 17 Jan 2014 00:01:16 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id D77EF1ADDDA; Fri, 17 Jan 2014 00:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5327; q=dns/txt; s=iport; t=1389945663; x=1391155263; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=HkNOnSrKshcyZgyC1QqFaG1vRHO+lLYRO3/AWaq7eqk=; b=RhXuVLqMzrvGbEPniQgGMZqBjMcR6ZDVawA1TWz2SsKJnxFd7f5CuSkH VR9r/Lla9H74ucH+1qfg3RDM5qkh+5eHSqdvIhebqFtVeuqNEGURn6jND 57D6/wlknFnOOQBYodUSIbXNlKC1z6S+m6O8CyfZ5b0cfkbRoNyOGImo3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJFf2FKQ/khR/2dsb2JhbABZgws4u2eBDxZ0giYBAQQ4QBEsFg8JAwIBAgE7CgYBDAgBAYgADcU0F48GhDgEmCGBMYUVi1GBb4E/Ow X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="scan'208";a="3087765" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 17 Jan 2014 08:01:01 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0H81101016188; Fri, 17 Jan 2014 08:01:01 GMT Message-ID: <52D8E33D.5070102@cisco.com> Date: Fri, 17 Jan 2014 09:01:01 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20140117000150.30143.12438.idtracker@ietfa.amsl.com> In-Reply-To: <20140117000150.30143.12438.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140117000150.30143.12438.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2014-01-23 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 08:01:18 -0000 Dear all, Please find below the agenda of the Jan 23rd IESG telechat. Please send your questions, comments and concerns before Jan 22nd COB. Thanks and Regards, Benoit. INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2014-01-23 IESG Teleconference This agenda was generated at 2014-01-16 16:00:35 PST Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-6man-stable-privacy-addresses-16 - IETF stream A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (Proposed Standard) Token: Brian Haberman IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-netmod-interfaces-cfg-15 - IETF stream A YANG Data Model for Interface Management (Proposed Standard) Token: Benoit Claise IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-isis-rfc6326bis-01 - IETF stream Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS (Proposed Standard) Token: Adrian Farrel IANA Review: IANA - Review Needed Consensus: No Last call expires: 2014-01-22 o draft-ietf-ccamp-oam-configuration-fwk-12 - IETF stream GMPLS RSVP-TE extensions for OAM Configuration (Proposed Standard) Token: Adrian Farrel IANA Review: Version Changed - Review Needed Consensus: Yes o draft-ietf-netmod-system-mgmt-10 - IETF stream A YANG Data Model for System Management (Proposed Standard) Token: Benoit Claise IANA Review: IANA OK - Actions Needed Consensus: Yes Last call expires: 2014-01-22 o draft-ietf-pwe3-mpls-tp-cv-adv-04 - IETF stream VCCV MPLS-TP Connectivity Verification (CV) Capability Advertisement (Proposed Standard) Token: Stewart Bryant IANA Review: IANA - Not OK Consensus: Yes o draft-ietf-mpls-moving-iana-registries-03 - IETF stream Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry (Proposed Standard) Token: Adrian Farrel IANA Review: IANA OK - Actions Needed Consensus: Unknown Last call expires: 2014-01-17 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-shore-icmp-aup-09 - IETF stream An Acceptable Use Policy for New ICMP Types and Codes (Best Current Practice) Token: Benoit Claise IANA Review: IANA OK - No Actions Needed Consensus: Unknown 2.2.2 Returning Items o draft-farrell-perpass-attack-03 - IETF stream Pervasive Monitoring is an Attack (Best Current Practice) Token: Jari Arkko IANA Review: Version Changed - Review Needed Consensus: Unknown 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-l2vpn-evpn-req-06 - IETF stream Requirements for Ethernet VPN (EVPN) (Informational) Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-opsawg-lsn-deployment-04 - IETF stream CGN Deployment with BGP/MPLS IP VPNs (Informational) Token: Benoit Claise IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-mpls-multipath-use-03 - IETF stream Use of Multipath with MPLS and MPLS-TP (Informational) Token: Adrian Farrel IANA Review: IANA OK - No Actions Needed Consensus: Unknown Last call expires: 2014-01-17 o draft-ietf-mpls-tp-p2mp-framework-05 - IETF stream A Framework for Point-to-Multipoint MPLS in Transport Networks (Informational) Token: Adrian Farrel IANA Review: IANA OK - No Actions Needed Consensus: Yes 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-moriarty-pkcs12v1-1-03 - IETF stream PKCS #12: Personal Information Exchange Syntax v1.1 (Informational) Token: Sean Turner IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-housley-number-registries-02 - IETF stream Internet Numbers Registries (Informational) Token: Jari Arkko IANA Review: IANA OK - Actions Needed Consensus: Unknown Last call expires: 2014-01-22 3.2.2 Returning Items NONE 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 3.4.3 For Action o conflict-review-goix-appsawg-enum-acct-uri-00 IETF conflict review for draft-goix-appsawg-enum-acct-uri draft-goix-appsawg-enum-acct-uri-06 ENUM Service Registration for acct URI (ISE: Experimental) Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Transparency (trans) 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From j.schoenwaelder@jacobs-university.de Sun Jan 19 10:22:51 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BA11ADF70; Sun, 19 Jan 2014 10:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 gmW-wcM-B5XY; Sun, 19 Jan 2014 10:22:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 713A81ADF38; Sun, 19 Jan 2014 10:22:48 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0264520056; Sun, 19 Jan 2014 19:22:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JE1m7bvH9XB2; Sun, 19 Jan 2014 19:22:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95ACA2003F; Sun, 19 Jan 2014 19:22:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 77FDB2ABDB8C; Sun, 19 Jan 2014 19:22:31 +0100 (CET) Date: Sun, 19 Jan 2014 19:22:31 +0100 From: Juergen Schoenwaelder To: draft-ietf-pce-pcep-mib.all@tools.ietf.org, pce@ietf.org Message-ID: <20140119182231.GB42438@elstar.local> Mail-Followup-To: draft-ietf-pce-pcep-mib.all@tools.ietf.org, pce@ietf.org, mib-doctors@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mib-doctors@ietf.org Subject: [MIB-DOCTORS] 'MIB Doctor' review of draft-ietf-pce-pcep-mib-06 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 18:22:52 -0000 Hi, please find below my review of draft-ietf-pce-pcep-mib-06. Overall, the document is in a pretty good shape. It is nice to review MIB modules that are well put together. The MIB module compiles fine with smiling 0.4.8 and produces no warnings. Below is a list of comments in document order of appearance. Some may require an action other maybe not. I have marked the ones that I find more important with (*). a) I guess you should spell out PCE In the title. b) The abstract says the I-D defines an "experimental portion" of the MIB while the document is marked as standards-track. This does not seem to be consistent. c) In section 2, ATD should STD. d) The LAST-UPDATED and REVISION clauses as well as the Copyright year in the DESCRIPTION clause of the MODULE-IDENTITY all date back to 2013 even though the I-D was last updated in 2014. You may want to move to a date in 2014. e) I suggest to replace pcePcepMIBObjects with pcePcepObjects. This aligns more with the recommendation given in appendix D of RFC 4181. f) I think the description of pcePcepEntityTable should use plural, that is, "... about PCEP Entities". Or will this table always have only a single row? g) If you want to describe the enums of an INTEGER, please do so in the DESCRIPTION clause and not in comments (since comments may not be preserved by tools processing MIB modules). h) pcePcepEntityAddr seems to serve two purposes, depending on whether the peer is a pce and a pcc. The pcePcepPeerRole object makes me believe an entity can also be both at the same time. If so, then how does one interpret pcePcepEntityAddr? (*) i) pcePcepEntityConnectMaxRetry has a UNITS clause saying it is in seconds. This might be a cut and paste error? j) pcePcepPeerAddr has a length restriction which essentially also restricts pcePcepPeerAddrType. pcePcepPeerAddrType kind of has a restriction inline but not explicit via subtyping. It might be more inline with the INET-ADDRESS-MIB to not restrict this. If you want to restrict things, you may want to do that in a compliance statement. (*) Despite future proofing considerations, the restrictions make it impossible to have PCE entities with non-global that is non-unique addresses (because you may not be able to disambiguate them). k) pcePcepPeerDiscontinuityTime refers to RFC 1907. I think the current version it should refer to is RFC 3418. In any case, if you think explicit text concerning sysUpTime is needed, I think this warrants a normative reference added to RFC 3418 and a statement in section 5.5. (I am not sure this is really needed since you kind of import knowledge about sysUpTime via the TimeStamp TC you are using. j) The *AvgRspTime, *LWMRspTime, *HWMRspTime objects have a resolution of seconds. This means that times < 500ms will be represented as 0 seconds and thus indistinguishable from no message at all. I do not know whether this is an issue or not. Is it possible to have sub-second response times? (*) k) pcePcepSessState typo: entiries -> entries l) pcePcepSessPeerDeadTimer typo: for for -> for -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From venkat.mahalingams@gmail.com Sun Jan 19 12:40:47 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE44D1AD10A for ; Sun, 19 Jan 2014 12:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] 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 y575zWxk8Mza for ; Sun, 19 Jan 2014 12:40:45 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0D1ACC7E for ; Sun, 19 Jan 2014 12:40:45 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id x55so6083231wes.8 for ; Sun, 19 Jan 2014 12:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=x5ndlHXhFNU0OIlEQJvbI2Uv2n46nlwUtxmpaa0RTFc=; b=T7lgDIhqfJhJIriZ8R5c8J5VgH0uW5TpIE24kXEP1gpDPYZyPvwyY0XlaEWgbxljC4 mTzEdZGMrZoKkTR6B9wpVYXDA3Asemv0Cyqj4PrbIcjya+RN9WDINjmvRFGTIkuOjszn MAznA3v0Sxe+pU/I/Cy91iWms7bddjn+IaUnJZ9jWfvTzOeGjt4Yodcfk/gWPR8r1Amp rmdjg3Qtxp966IMih0Vm06MuB5y4jSp1uQxdO047Zb0GuODABJ57peEh8Xqt0ilnPYO9 peQpWtu9om8zbndULWEMMF5s6SD0NTSokq9zk2jIeEktE88i7lTBF94efjIeOzy3MefR yHrQ== MIME-Version: 1.0 X-Received: by 10.180.76.168 with SMTP id l8mr7258584wiw.40.1390164031414; Sun, 19 Jan 2014 12:40:31 -0800 (PST) Received: by 10.227.108.129 with HTTP; Sun, 19 Jan 2014 12:40:31 -0800 (PST) In-Reply-To: References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> Date: Sun, 19 Jan 2014 12:40:31 -0800 Message-ID: From: Venkatesan Mahalingam To: "draft-ietf-mpls-tp-te-mib@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Thomas Nadeau , Sam Aldrin , Kannan Sampath , adrian , "MIB Doctors (E-mail)" Content-Type: multipart/alternative; boundary=f46d0437499745a5f404f058c98c Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 20:40:48 -0000 --f46d0437499745a5f404f058c98c Content-Type: text/plain; charset=ISO-8859-1 ++Adrian and MIB doctors. On Sunday, January 19, 2014, Venkatesan Mahalingam < venkat.mahalingams@gmail.com> wrote: > Hi All, > > As we have quite a few review comments from AD, we are addressing them in > the private mail thread below. > > >>I think you should discuss with your document shepherd whether to > release the > >>changes in batches as you go along, or wait for all the changes in one > go. > > *Loa:* How would you like to proceed? Shall we release the changes in > batches or all changes in one go? > > As some of the authors are in vacation now, could not spend much time for > discussing the comments. Hopefully, we will make this document into good > shape by end of this month. > > *Adrian: *Thanks for your response. We(Authors) shall discuss further on > your below comments and update you as early as possible. > > >>Is there a reason to have this discussion in private and missing one of > your > >>co-authors? > Nope. Tom's Juniper email was bouncing and later I forgot to add him in > the mail thread. It's my bad..;-) > > -Venkat. > > ---------- Forwarded message ---------- > From: Adrian Farrel 'adrian@olddog.co.uk');>> > Date: Sun, Jan 19, 2014 at 10:24 AM > Subject: RE: AD review of draft-ietf-mpls-tp-te-mib > To: Venkatesan Mahalingam > > > Cc: Sam Aldrin 'sam.aldrin@gmail.com');>>, Kannan Sampath > > > > > Hello, > Sorry for the delay. > > Is there a reason to have this discussion in private and missing one of > your > co-authors? > Don't forget that you'll need to explain o the working group and your > document > shepherd what you have changed and why. > > I have edited out the points where we have full agreement. > > Thanks for the work so far. I think we have some more to do. > > I think you should discuss with your document shepherd whether to release > the > changes in batches as you go along, or wait for all the changes in one go. > > Cheers, > Adrian > > > It would be nice if someone could do a pass on this document for > > English and format. It is not essential because the RFC Editor will > > resolve these issues, but it is wise because the fewer changes the RFC > > Editor makes, the less chance there is of an accidental error. > > VM>> OK. > > Does "OK" mean that you agree with me that it would be nice, but that > nothing > will happen? > > > I see a contradiction in > > > > In > > particular, it describes managed objects of Tunnels, Identifiers, Label > > Switching Router and Textual conventions for Multiprotocol Label > > Switching (MPLS) based Transport Profile (TP). These MIB modules extend > > the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP > > operations, so the MPLS-TP name is not included in the MIB module name. > > > > Either the extensions are for MPLS-TP or they are not. Your second > > sentence says they are for more general applicability, and I agree with > > that. So why does the first sentence and the document title talk about > > MPLS-TP? > > > > VM>> Per Loa suggestion, we kept the mpls-tp in the title because we > > develop this MIB module as part of IETF MPLS-TP project. > > First sentence will be changed. > > I see the change and am now faced with "untraditional networks" which I > like > even less. > > I wish you could decide what this MIB module is for and describe that. > Note that > this problem runs through the document where you talk about objects and > tables > being for MPLS-TP tunnels, etc. > > > I think the Introduction would be made more useful and relevant if it > > described the purpose and content of this document. Currently it says > > what the existing documents don't do (although even that is pretty > > vague). > > You added a few words per the Abstract, but you didn't really change the > text. > Can you say what function you are adding support for. That would probably > address my concern. > > And you left in place... > > > The existing Multiprotocol Label Switching (MPLS) Traffic Engineering > > (TE) Management Information Base (MIB) [RFC3812] and Generalized > > Multiprotocol Label Switching (GMPLS) Traffic Engineering Management > > Information Base [RFC4802] do not support the transport network > > requirements of NON-IP based management and static bidirectional > > tunnels. > > ...which says what other documents don;t allow you to do, but not what this > document does. > > Furthermore, I previously said... > > > There is also an implication here that this MIB module supports non-IP > > based management. I looked but didn't see any description of how to run > > SNMP in the absence of IP. > > And I don't see any change for this. > How does an SNMP MIB module support non-IP based management? > > > It goes on... > > > > These MIB modules should be used in conjunction with [RFC3812] > > and companion document [RFC3813] for MPLS-TP tunnel configuration and > > management. > > > > What is an "MPLS-TP tunnel"? > > > > VM>> This document mainly focuses on static bi-directional tunnel. > > We'll update the introduction section to provide more details. > > I think you mean tunnels that are not set up by signaling? > What does "mainly" mean? > > You now have... > > This document mainly focuses on static > bidirectional MIB modules that should be used in conjunction with > [RFC3812] and companion document [RFC3813] for MPLS Transport Profile > (MPLS-TP) path configuration and management. > > What is a "static bidirectional MIB module". > What is an "MPLS-TP path"? How does it differ from an MPLS path? > > > Section 4 might have been an opportunity to provide the information I > > think is missing from the Introduction. But unfortunately it repeats > > some of the text form the Introduction and then gives a very scanty > > description of the purpose of the work. > > > > Here, however, I find the text > > > > As the existing MPLS- > > TE-STD-MIB is not sufficient to capture all the ch > > --f46d0437499745a5f404f058c98c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ++Adrian and MIB doctors.

On Sunday, January 19, 2014, = Venkatesan Mahalingam <v= enkat.mahalingams@gmail.com> wrote:
Hi All,

As we have quite a few review c= omments from AD, we are addressing them in the private mail thread below.

>>I think you should discuss with your document= shepherd whether to release the
>>changes in batches as you go along, or wait for all the changes in = one go.

Loa: How would you like to proc= eed? Shall we release the changes in batches or all changes in one go?

As some of the authors are in vacation now, could not s= pend much time for discussing the comments. Hopefully, we will make this do= cument into good shape by end of this month.

Adrian: Thanks for your response.=A0We(Authors) shall discuss furthe= r on your below comments and update you as early as possible.

>>Is there a reason to have this discussion in pr= ivate and missing one of your
>>co-authors?
Nope. To= m's Juniper email was bouncing and later I forgot to add him in the mai= l thread. It's my bad..;-)

-Venkat.

---------- Forwa= rded message ----------
From: Adrian Farre= l <adrian@olddog.co.uk>= ;
Date: Sun, Jan 19, 2014 at 10:24 AM
Subject: RE: AD review of draft-ietf= -mpls-tp-te-mib
To: Venkatesan Mahalingam <venkat.mahalingams@gmail.com>
Cc: Sam Aldrin <sam.aldrin@gmail.com>, Kann= an Sampath <kannankvs@gmail.com>


Hello,
Sorry for the delay.

Is there a reason to have this discussion in private and missing one of you= r
co-authors?
Don't forget that you'll need to explain o the working group and yo= ur document
shepherd what you have changed and why.

I have edited out the points where we have full agreement.

Thanks for the work so far. I think we have some more to do.

I think you should discuss with your document shepherd whether to release t= he
changes in batches as you go along, or wait for all the changes in one go.<= br>
Cheers,
Adrian

> It would be nice if someone could do a pass on this document for
> English and format. It is not essential because the RFC Editor will > resolve these issues, but it is wise because the fewer changes the RFC=
> Editor makes, the less chance there is of an accidental error.
> VM>> OK.

Does "OK" mean that you agree with me that it would be nice= , but that nothing
will happen?

> I see a contradiction in
>
>=A0In
>=A0particular, it describes managed objects of Tunnels, Identifiers, La= bel
>=A0Switching Router and Textual conventions for Multiprotocol Label
>=A0Switching (MPLS) based Transport Profile (TP). These MIB modules ext= end
>=A0the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP
>=A0operations, so the MPLS-TP name is not included in the MIB module na= me.
>
> Either the extensions are for MPLS-TP or they are not. Your second
> sentence says they are for more general applicability, and I agree wit= h
> that. So why does the first sentence and the document title talk about=
> MPLS-TP?
>
> VM>> Per Loa suggestion, we kept the mpls-tp in the title becaus= e we
> develop this MIB module as part of IETF MPLS-TP project.
> First sentence will be changed.

I see the change and am now faced with "untraditional networks&q= uot; which I like
even less.

I wish you could decide what this MIB module is for and describe that. Note= that
this problem runs through the document where you talk about objects and tab= les
being for MPLS-TP tunnels, etc.

> I think the Introduction would be made more useful and relevant if it<= br> > described the purpose and content of this document. Currently it says<= br> > what the existing documents don't do (although even that is pretty=
> vague).

You added a few words per the Abstract, but you didn't really cha= nge the text.
Can you say what function you are adding support for. That would probably address my concern.

And you left in place...

>=A0The existing Multiprotocol Label Switching (MPLS) Traffic Engineerin= g
>=A0(TE) Management Information Base (MIB) [RFC3812] and Generalized
>=A0Multiprotocol Label Switching (GMPLS) Traffic Engineering Management=
>=A0Information Base [RFC4802] do not support the transport network
>=A0requirements of NON-IP based management and static bidirectional
>=A0tunnels.

...which says what other documents don;t allow you to do, but not wha= t this
document does.

Furthermore, I previously said...

> There is also an implication here that this MIB module supports non-IP=
> based management. I looked but didn't see any description of how t= o run
> SNMP in the absence of IP.

And I don't see any change for this.
How does an SNMP MIB module support non-IP based management?

> It goes on...
>
>=A0These MIB modules should be used in conjunction with [RFC3812]
>=A0and companion document [RFC3813] for MPLS-TP tunnel configuration an= d
>=A0management.
>
> What is an "MPLS-TP tunnel"?
>
> VM>> This document mainly focuses on static bi-directional tunne= l.
> We'll update the introduction section to provide more details.

I think you mean tunnels that are not set up by signaling?
What does "mainly" mean?

You now have...

=A0 =A0 This document mainly focuses on static
=A0 =A0 bidirectional MIB modules that should be used in conjunction = with
=A0 =A0 [RFC3812] and companion document [RFC3813] for MPLS Transport Profi= le
=A0 =A0 (MPLS-TP) path configuration and management.

What is a "static bidirectional MIB module".
What is an "MPLS-TP path"? How does it differ from an MPLS path?<= br>

> Section 4 might have been an opportunity to provide the information I<= br> > think is missing from the Introduction. But unfortunately it repeats > some of the text form the Introduction and then gives a very scanty > description of the purpose of the work.
>
> Here, however, I find the text
>
>=A0As the existing MPLS-
>=A0TE-STD-MIB is not sufficient to capture all the ch

--f46d0437499745a5f404f058c98c-- From loa@pi.nu Sun Jan 19 19:10:48 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DAF1A0023 for ; Sun, 19 Jan 2014 19:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.065 X-Spam-Level: X-Spam-Status: No, score=0.065 tagged_above=-999 required=5 tests=[J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535] 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 aEjLfBKucXzc for ; Sun, 19 Jan 2014 19:10:47 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id C3A191A001F for ; Sun, 19 Jan 2014 19:10:46 -0800 (PST) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4C339180150F; Mon, 20 Jan 2014 04:10:42 +0100 (CET) Message-ID: <52DC93AE.7090000@pi.nu> Date: Mon, 20 Jan 2014 11:10:38 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Venkatesan Mahalingam , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Thomas Nadeau , Sam Aldrin , Kannan Sampath , adrian , "MIB Doctors (E-mail)" References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 03:10:49 -0000 All, I don't know how to say this politely. The working group, the authors and the mib-doctors have put in a substantial amount of time and effort to get the document in shape. Not being a MIB-expert the shepherd have relied heavily on the MIB-doctors. A process that worked well in the past. Three different versions were iterated between the MIB-doctors and the authors and updated according the comments from the MIB-doctor. This process ends by the MIB-doctor saying that it is OK to request publication. I'm a bit lost - but will try to work with authors and MIB-doctors to get the document in shape. Question to Adrian: Scanning through your comments I have the impression that the actual MIB-modules are more or less ok, but that the informative text is what needs to be updated, right? I also notice that the authors agreed to to a grammar review. /Loa On 2014-01-20 04:40, Venkatesan Mahalingam wrote: > ++Adrian and MIB doctors. > > On Sunday, January 19, 2014, Venkatesan Mahalingam > > wrote: > > Hi All, > > As we have quite a few review comments from AD, we are addressing > them in the private mail thread below. > > >>I think you should discuss with your document shepherd whether to > release the > >>changes in batches as you go along, or wait for all the changes > in one go. > > *Loa:* How would you like to proceed? Shall we release the changes > in batches or all changes in one go? > > As some of the authors are in vacation now, could not spend much > time for discussing the comments. Hopefully, we will make this > document into good shape by end of this month. > > *Adrian: *Thanks for your response. We(Authors) shall discuss > further on your below comments and update you as early as possible. > > >>Is there a reason to have this discussion in private and missing > one of your > >>co-authors? > Nope. Tom's Juniper email was bouncing and later I forgot to add him > in the mail thread. It's my bad..;-) > > -Venkat. > > ---------- Forwarded message ---------- > From: *Adrian Farrel* 'cvml', 'adrian@olddog.co.uk');>> > Date: Sun, Jan 19, 2014 at 10:24 AM > Subject: RE: AD review of draft-ietf-mpls-tp-te-mib > To: Venkatesan Mahalingam > > Cc: Sam Aldrin 'sam.aldrin@gmail.com');>>, Kannan Sampath > > > > Hello, > Sorry for the delay. > > Is there a reason to have this discussion in private and missing one > of your > co-authors? > Don't forget that you'll need to explain o the working group and > your document > shepherd what you have changed and why. > > I have edited out the points where we have full agreement. > > Thanks for the work so far. I think we have some more to do. > > I think you should discuss with your document shepherd whether to > release the > changes in batches as you go along, or wait for all the changes in > one go. > > Cheers, > Adrian > > > It would be nice if someone could do a pass on this document for > > English and format. It is not essential because the RFC Editor will > > resolve these issues, but it is wise because the fewer changes > the RFC > > Editor makes, the less chance there is of an accidental error. > > VM>> OK. > > Does "OK" mean that you agree with me that it would be nice, but > that nothing > will happen? > > > I see a contradiction in > > > > In > > particular, it describes managed objects of Tunnels, Identifiers, > Label > > Switching Router and Textual conventions for Multiprotocol Label > > Switching (MPLS) based Transport Profile (TP). These MIB modules > extend > > the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP > > operations, so the MPLS-TP name is not included in the MIB module > name. > > > > Either the extensions are for MPLS-TP or they are not. Your second > > sentence says they are for more general applicability, and I > agree with > > that. So why does the first sentence and the document title talk > about > > MPLS-TP? > > > > VM>> Per Loa suggestion, we kept the mpls-tp in the title because we > > develop this MIB module as part of IETF MPLS-TP project. > > First sentence will be changed. > > I see the change and am now faced with "untraditional networks" > which I like > even less. > > I wish you could decide what this MIB module is for and describe > that. Note that > this problem runs through the document where you talk about objects > and tables > being for MPLS-TP tunnels, etc. > > > I think the Introduction would be made more useful and relevant if it > > described the purpose and content of this document. Currently it says > > what the existing documents don't do (although even that is pretty > > vague). > > You added a few words per the Abstract, but you didn't really change > the text. > Can you say what function you are adding support for. That would > probably > address my concern. > > And you left in place... > > > The existing Multiprotocol Label Switching (MPLS) Traffic Engineering > > (TE) Management Information Base (MIB) [RFC3812] and Generalized > > Multiprotocol Label Switching (GMPLS) Traffic Engineering Management > > Information Base [RFC4802] do not support the transport network > > requirements of NON-IP based management and static bidirectional > > tunnels. > > ...which says what other documents don;t allow you to do, but not > what this > document does. > > Furthermore, I previously said... > > > There is also an implication here that this MIB module supports > non-IP > > based management. I looked but didn't see any description of how > to run > > SNMP in the absence of IP. > > And I don't see any change for this. > How does an SNMP MIB module support non-IP based management? > > > It goes on... > > > > These MIB modules should be used in conjunction with [RFC3812] > > and companion document [RFC3813] for MPLS-TP tunnel configuration and > > management. > > > > What is an "MPLS-TP tunnel"? > > > > VM>> This document mainly focuses on static bi-directional tunnel. > > We'll update the introduction section to provide more details. > > I think you mean tunnels that are not set up by signaling? > What does "mainly" mean? > > You now have... > > This document mainly focuses on static > bidirectional MIB modules that should be used in conjunction with > [RFC3812] and companion document [RFC3813] for MPLS Transport > Profile > (MPLS-TP) path configuration and management. > > What is a "static bidirectional MIB module". > What is an "MPLS-TP path"? How does it differ from an MPLS path? > > > Section 4 might have been an opportunity to provide the information I > > think is missing from the Introduction. But unfortunately it repeats > > some of the text form the Introduction and then gives a very scanty > > description of the purpose of the work. > > > > Here, however, I find the text > > > > As the existing MPLS- > > TE-STD-MIB is not sufficient to capture all the ch > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From bclaise@cisco.com Sun Jan 19 23:24:25 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C753F1A006A for ; Sun, 19 Jan 2014 23:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.436 X-Spam-Level: X-Spam-Status: No, score=-9.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FmPoJOcuS4hq for ; Sun, 19 Jan 2014 23:24:23 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC511A0068 for ; Sun, 19 Jan 2014 23:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8609; q=dns/txt; s=iport; t=1390202663; x=1391412263; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=8GuKZitfqT817idoJOzf+GiESQZcLBXAx6zrAkN9L84=; b=Q5pS0pIymQZ3zRHmJ9KKdmipFBdrSgyHth+uIB9q/7Gh2a6xpjS/BQYt QoLsnxaHLqMHG8++PctAMxdOh59l66QMXdIVZZXdrwtpCYGgp1Hv0sGwZ RH13hKRiHeY83rSC48I/qL2MyX8/WvVNvDnutY+MkEzQ/uOIwNoZ1dvnV w=; X-IronPort-AV: E=Sophos;i="4.95,689,1384300800"; d="scan'208";a="3875231" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 20 Jan 2014 07:24:22 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0K7OLcH015413; Mon, 20 Jan 2014 07:24:21 GMT Message-ID: <52DCCF25.9010405@cisco.com> Date: Mon, 20 Jan 2014 08:24:21 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Loa Andersson , Venkatesan Mahalingam , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Thomas Nadeau , Sam Aldrin , Kannan Sampath , adrian , "MIB Doctors (E-mail)" , me References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> In-Reply-To: <52DC93AE.7090000@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 07:24:26 -0000 Loa, > All, > > I don't know how to say this politely. > > The working group, the authors and the mib-doctors have put in a > substantial amount of time and effort to get the document in shape. > > Not being a MIB-expert the shepherd have relied heavily on the > MIB-doctors. A process that worked well in the past. > > Three different versions were iterated between the MIB-doctors and > the authors and updated according the comments from the MIB-doctor. > This process ends by the MIB-doctor saying that it is OK to request > publication. > > I'm a bit lost - but will try to work with authors and MIB-doctors to > get the document in shape. I'm not sure I understand your email, or to be more precise, what you expect from the MIB doctor? I concluded that MIB doctors review was done on this document. http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history Am I wrong? > > Question to Adrian: Scanning through your comments I have the impression > that the actual MIB-modules are more or less ok, but that the > informative text is what needs to be updated, right? I don't see any MIB related feedback in this email. Regards, Benoit > I also notice that > the authors agreed to to a grammar review. > > /Loa > > On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >> ++Adrian and MIB doctors. >> >> On Sunday, January 19, 2014, Venkatesan Mahalingam >> > >> wrote: >> >> Hi All, >> >> As we have quite a few review comments from AD, we are addressing >> them in the private mail thread below. >> >> >>I think you should discuss with your document shepherd whether to >> release the >> >>changes in batches as you go along, or wait for all the changes >> in one go. >> >> *Loa:* How would you like to proceed? Shall we release the changes >> in batches or all changes in one go? >> >> As some of the authors are in vacation now, could not spend much >> time for discussing the comments. Hopefully, we will make this >> document into good shape by end of this month. >> >> *Adrian: *Thanks for your response. We(Authors) shall discuss >> further on your below comments and update you as early as possible. >> >> >>Is there a reason to have this discussion in private and missing >> one of your >> >>co-authors? >> Nope. Tom's Juniper email was bouncing and later I forgot to add him >> in the mail thread. It's my bad..;-) >> >> -Venkat. >> >> ---------- Forwarded message ---------- >> From: *Adrian Farrel* > 'cvml', 'adrian@olddog.co.uk');>> >> Date: Sun, Jan 19, 2014 at 10:24 AM >> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >> To: Venkatesan Mahalingam > > >> Cc: Sam Aldrin > 'sam.aldrin@gmail.com');>>, Kannan Sampath > > >> >> >> Hello, >> Sorry for the delay. >> >> Is there a reason to have this discussion in private and missing one >> of your >> co-authors? >> Don't forget that you'll need to explain o the working group and >> your document >> shepherd what you have changed and why. >> >> I have edited out the points where we have full agreement. >> >> Thanks for the work so far. I think we have some more to do. >> >> I think you should discuss with your document shepherd whether to >> release the >> changes in batches as you go along, or wait for all the changes in >> one go. >> >> Cheers, >> Adrian >> >> > It would be nice if someone could do a pass on this document for >> > English and format. It is not essential because the RFC Editor >> will >> > resolve these issues, but it is wise because the fewer changes >> the RFC >> > Editor makes, the less chance there is of an accidental error. >> > VM>> OK. >> >> Does "OK" mean that you agree with me that it would be nice, but >> that nothing >> will happen? >> >> > I see a contradiction in >> > >> > In >> > particular, it describes managed objects of Tunnels, Identifiers, >> Label >> > Switching Router and Textual conventions for Multiprotocol Label >> > Switching (MPLS) based Transport Profile (TP). These MIB modules >> extend >> > the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >> > operations, so the MPLS-TP name is not included in the MIB module >> name. >> > >> > Either the extensions are for MPLS-TP or they are not. Your >> second >> > sentence says they are for more general applicability, and I >> agree with >> > that. So why does the first sentence and the document title talk >> about >> > MPLS-TP? >> > >> > VM>> Per Loa suggestion, we kept the mpls-tp in the title >> because we >> > develop this MIB module as part of IETF MPLS-TP project. >> > First sentence will be changed. >> >> I see the change and am now faced with "untraditional networks" >> which I like >> even less. >> >> I wish you could decide what this MIB module is for and describe >> that. Note that >> this problem runs through the document where you talk about objects >> and tables >> being for MPLS-TP tunnels, etc. >> >> > I think the Introduction would be made more useful and >> relevant if it >> > described the purpose and content of this document. Currently >> it says >> > what the existing documents don't do (although even that is >> pretty >> > vague). >> >> You added a few words per the Abstract, but you didn't really change >> the text. >> Can you say what function you are adding support for. That would >> probably >> address my concern. >> >> And you left in place... >> >> > The existing Multiprotocol Label Switching (MPLS) Traffic >> Engineering >> > (TE) Management Information Base (MIB) [RFC3812] and Generalized >> > Multiprotocol Label Switching (GMPLS) Traffic Engineering >> Management >> > Information Base [RFC4802] do not support the transport network >> > requirements of NON-IP based management and static bidirectional >> > tunnels. >> >> ...which says what other documents don;t allow you to do, but not >> what this >> document does. >> >> Furthermore, I previously said... >> >> > There is also an implication here that this MIB module supports >> non-IP >> > based management. I looked but didn't see any description of how >> to run >> > SNMP in the absence of IP. >> >> And I don't see any change for this. >> How does an SNMP MIB module support non-IP based management? >> >> > It goes on... >> > >> > These MIB modules should be used in conjunction with [RFC3812] >> > and companion document [RFC3813] for MPLS-TP tunnel >> configuration and >> > management. >> > >> > What is an "MPLS-TP tunnel"? >> > >> > VM>> This document mainly focuses on static bi-directional >> tunnel. >> > We'll update the introduction section to provide more details. >> >> I think you mean tunnels that are not set up by signaling? >> What does "mainly" mean? >> >> You now have... >> >> This document mainly focuses on static >> bidirectional MIB modules that should be used in conjunction >> with >> [RFC3812] and companion document [RFC3813] for MPLS Transport >> Profile >> (MPLS-TP) path configuration and management. >> >> What is a "static bidirectional MIB module". >> What is an "MPLS-TP path"? How does it differ from an MPLS path? >> >> > Section 4 might have been an opportunity to provide the >> information I >> > think is missing from the Introduction. But unfortunately it >> repeats >> > some of the text form the Introduction and then gives a very >> scanty >> > description of the purpose of the work. >> > >> > Here, however, I find the text >> > >> > As the existing MPLS- >> > TE-STD-MIB is not sufficient to capture all the ch >> > From loa@pi.nu Mon Jan 20 01:31:35 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794601A0050 for ; Mon, 20 Jan 2014 01:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535] 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 I4CJGcS_373S for ; Mon, 20 Jan 2014 01:31:32 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BB04A1A001D for ; Mon, 20 Jan 2014 01:31:31 -0800 (PST) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D826A180150F; Mon, 20 Jan 2014 10:31:24 +0100 (CET) Message-ID: <52DCECE6.3040708@pi.nu> Date: Mon, 20 Jan 2014 17:31:18 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Benoit Claise , Venkatesan Mahalingam , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Thomas Nadeau , Sam Aldrin , Kannan Sampath , adrian , "MIB Doctors (E-mail)" References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> <52DCCF25.9010405@cisco.com> In-Reply-To: <52DCCF25.9010405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 09:31:35 -0000 Benoit, Joan (and all of the MIB Doctors), I apologize - rereading my mail I understand why you read it the way you do. I think I have a pretty good understanding of what the MIB Doctors do and can do. And I think the support for this particular document has been outstanding. There is something else (if we agree that there are no MIB related feedback on this document). I'm afraid that with the type of AD review we got here we will scare people away even though they produce technically sound documents. If this is a clarity, grammar and Queens English question, I would say that it would been much more efficient to simply state: "I can see that this document is almost done from a technical perspective, but it lacks quite a bit from language and grammar. Can you please to a language review before we proceed?" It was also my point that I don't see if Adrian's comments are MIB module related or "just" a language thing. And that is part of why I copied the people on Venkat's mail. /Loa On 2014-01-20 15:24, Benoit Claise wrote: > Loa, > > >> All, >> >> I don't know how to say this politely. >> >> The working group, the authors and the mib-doctors have put in a >> substantial amount of time and effort to get the document in shape. >> >> Not being a MIB-expert the shepherd have relied heavily on the >> MIB-doctors. A process that worked well in the past. >> >> Three different versions were iterated between the MIB-doctors and >> the authors and updated according the comments from the MIB-doctor. >> This process ends by the MIB-doctor saying that it is OK to request >> publication. >> >> I'm a bit lost - but will try to work with authors and MIB-doctors to >> get the document in shape. > I'm not sure I understand your email, or to be more precise, what you > expect from the MIB doctor? > I concluded that MIB doctors review was done on this document. > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history > Am I wrong? >> >> Question to Adrian: Scanning through your comments I have the impression >> that the actual MIB-modules are more or less ok, but that the >> informative text is what needs to be updated, right? > I don't see any MIB related feedback in this email. > > Regards, Benoit >> I also notice that >> the authors agreed to to a grammar review. >> >> /Loa >> >> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >>> ++Adrian and MIB doctors. >>> >>> On Sunday, January 19, 2014, Venkatesan Mahalingam >>> > >>> wrote: >>> >>> Hi All, >>> >>> As we have quite a few review comments from AD, we are addressing >>> them in the private mail thread below. >>> >>> >>I think you should discuss with your document shepherd whether to >>> release the >>> >>changes in batches as you go along, or wait for all the changes >>> in one go. >>> >>> *Loa:* How would you like to proceed? Shall we release the changes >>> in batches or all changes in one go? >>> >>> As some of the authors are in vacation now, could not spend much >>> time for discussing the comments. Hopefully, we will make this >>> document into good shape by end of this month. >>> >>> *Adrian: *Thanks for your response. We(Authors) shall discuss >>> further on your below comments and update you as early as possible. >>> >>> >>Is there a reason to have this discussion in private and missing >>> one of your >>> >>co-authors? >>> Nope. Tom's Juniper email was bouncing and later I forgot to add him >>> in the mail thread. It's my bad..;-) >>> >>> -Venkat. >>> >>> ---------- Forwarded message ---------- >>> From: *Adrian Farrel* >> 'cvml', 'adrian@olddog.co.uk');>> >>> Date: Sun, Jan 19, 2014 at 10:24 AM >>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >>> To: Venkatesan Mahalingam >> > >>> Cc: Sam Aldrin >> 'sam.aldrin@gmail.com');>>, Kannan Sampath >> > >>> >>> >>> Hello, >>> Sorry for the delay. >>> >>> Is there a reason to have this discussion in private and missing one >>> of your >>> co-authors? >>> Don't forget that you'll need to explain o the working group and >>> your document >>> shepherd what you have changed and why. >>> >>> I have edited out the points where we have full agreement. >>> >>> Thanks for the work so far. I think we have some more to do. >>> >>> I think you should discuss with your document shepherd whether to >>> release the >>> changes in batches as you go along, or wait for all the changes in >>> one go. >>> >>> Cheers, >>> Adrian >>> >>> > It would be nice if someone could do a pass on this document for >>> > English and format. It is not essential because the RFC Editor >>> will >>> > resolve these issues, but it is wise because the fewer changes >>> the RFC >>> > Editor makes, the less chance there is of an accidental error. >>> > VM>> OK. >>> >>> Does "OK" mean that you agree with me that it would be nice, but >>> that nothing >>> will happen? >>> >>> > I see a contradiction in >>> > >>> > In >>> > particular, it describes managed objects of Tunnels, Identifiers, >>> Label >>> > Switching Router and Textual conventions for Multiprotocol Label >>> > Switching (MPLS) based Transport Profile (TP). These MIB modules >>> extend >>> > the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >>> > operations, so the MPLS-TP name is not included in the MIB module >>> name. >>> > >>> > Either the extensions are for MPLS-TP or they are not. Your >>> second >>> > sentence says they are for more general applicability, and I >>> agree with >>> > that. So why does the first sentence and the document title talk >>> about >>> > MPLS-TP? >>> > >>> > VM>> Per Loa suggestion, we kept the mpls-tp in the title >>> because we >>> > develop this MIB module as part of IETF MPLS-TP project. >>> > First sentence will be changed. >>> >>> I see the change and am now faced with "untraditional networks" >>> which I like >>> even less. >>> >>> I wish you could decide what this MIB module is for and describe >>> that. Note that >>> this problem runs through the document where you talk about objects >>> and tables >>> being for MPLS-TP tunnels, etc. >>> >>> > I think the Introduction would be made more useful and >>> relevant if it >>> > described the purpose and content of this document. Currently >>> it says >>> > what the existing documents don't do (although even that is >>> pretty >>> > vague). >>> >>> You added a few words per the Abstract, but you didn't really change >>> the text. >>> Can you say what function you are adding support for. That would >>> probably >>> address my concern. >>> >>> And you left in place... >>> >>> > The existing Multiprotocol Label Switching (MPLS) Traffic >>> Engineering >>> > (TE) Management Information Base (MIB) [RFC3812] and Generalized >>> > Multiprotocol Label Switching (GMPLS) Traffic Engineering >>> Management >>> > Information Base [RFC4802] do not support the transport network >>> > requirements of NON-IP based management and static bidirectional >>> > tunnels. >>> >>> ...which says what other documents don;t allow you to do, but not >>> what this >>> document does. >>> >>> Furthermore, I previously said... >>> >>> > There is also an implication here that this MIB module supports >>> non-IP >>> > based management. I looked but didn't see any description of how >>> to run >>> > SNMP in the absence of IP. >>> >>> And I don't see any change for this. >>> How does an SNMP MIB module support non-IP based management? >>> >>> > It goes on... >>> > >>> > These MIB modules should be used in conjunction with [RFC3812] >>> > and companion document [RFC3813] for MPLS-TP tunnel >>> configuration and >>> > management. >>> > >>> > What is an "MPLS-TP tunnel"? >>> > >>> > VM>> This document mainly focuses on static bi-directional >>> tunnel. >>> > We'll update the introduction section to provide more details. >>> >>> I think you mean tunnels that are not set up by signaling? >>> What does "mainly" mean? >>> >>> You now have... >>> >>> This document mainly focuses on static >>> bidirectional MIB modules that should be used in conjunction >>> with >>> [RFC3812] and companion document [RFC3813] for MPLS Transport >>> Profile >>> (MPLS-TP) path configuration and management. >>> >>> What is a "static bidirectional MIB module". >>> What is an "MPLS-TP path"? How does it differ from an MPLS path? >>> >>> > Section 4 might have been an opportunity to provide the >>> information I >>> > think is missing from the Introduction. But unfortunately it >>> repeats >>> > some of the text form the Introduction and then gives a very >>> scanty >>> > description of the purpose of the work. >>> > >>> > Here, however, I find the text >>> > >>> > As the existing MPLS- >>> > TE-STD-MIB is not sufficient to capture all the ch >>> >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Mon Jan 20 01:46:07 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCBD1A00B5 for ; Mon, 20 Jan 2014 01:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 H2gdOi8BkPKg for ; Mon, 20 Jan 2014 01:46:05 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 849541A00B2 for ; Mon, 20 Jan 2014 01:46:04 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0K9jumw025619; Mon, 20 Jan 2014 09:45:56 GMT Received: from 950129200 (15.21.90.92.rev.sfr.net [92.90.21.15]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0K9jpnT025519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Jan 2014 09:45:54 GMT From: "Adrian Farrel" To: "'Benoit Claise'" , "'Loa Andersson'" , "'Venkatesan Mahalingam'" , , , "'Thomas Nadeau'" , "'Sam Aldrin'" , "'Kannan Sampath'" , "'MIB Doctors \(E-mail\)'" References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> <52DCCF25.9010405@cisco.com> In-Reply-To: <52DCCF25.9010405@cisco.com> Date: Mon, 20 Jan 2014 09:45:54 -0000 Message-ID: <084201cf15c4$6c644e40$452ceac0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJUdMc+/eywYuHCZ8DkHT4JNheJ5QIUkcsyAd1rYTkBx+zWqwI935C6AXQZXP8CS4LqnZkk4VFQ Content-Language: en-gb Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 09:46:07 -0000 What I think Loa is saying is "help!" The MIB Doctor review was great and found a large number of issues with the document. Yet, when the document reached the AD for review there were still a significant number of issues with the MIB modules. I don't think that the MIB Doctor can be expected to review and re-review every document until it is perfect (they are welcome to, and we are delighted when they do, but they are human and they have day jobs), and I believe that sometimes it is simply not possible to find all issues in the first review because one set of problems obscure another set. Loa has forwarded a mail taken from part way through the email thread. A number of issues with the ANS.1 have been fixed by now, and this particular email was edited down to remove the technical issues and just leave the "political" ones. FWIW I have no issue with the level of review given to this document by the MIB Doctor. I do have an issue with the level of quality of this document as it came from the WG to first the MIB Doctor and then to me. It needs to be understood, IMHO, that people writing MIB modules are supposed to understand roughly what they are doing and to use the MIB doctors to verify the quality and catch a few missed issues. It is not the MIB Doctor's job to provide the ASN.1 for the authors! Loa is (rightly) wondering how he can get this sort of document up to quality when the WG is not very interested, the level of MIB clue in the WG is low, and the MIB Doctors are not super-heroes with days or weeks of spare time. I have no answer to that question except "Why do we keep writing write-access MIB modules?" Adrian > > The working group, the authors and the mib-doctors have put in a > > substantial amount of time and effort to get the document in shape. > > > > Not being a MIB-expert the shepherd have relied heavily on the > > MIB-doctors. A process that worked well in the past. > > > > Three different versions were iterated between the MIB-doctors and > > the authors and updated according the comments from the MIB-doctor. > > This process ends by the MIB-doctor saying that it is OK to request > > publication. > > > > I'm a bit lost - but will try to work with authors and MIB-doctors to > > get the document in shape. > I'm not sure I understand your email, or to be more precise, what you > expect from the MIB doctor? > I concluded that MIB doctors review was done on this document. > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history > Am I wrong? > > > > Question to Adrian: Scanning through your comments I have the impression > > that the actual MIB-modules are more or less ok, but that the > > informative text is what needs to be updated, right? > I don't see any MIB related feedback in this email. > > Regards, Benoit > > I also notice that > > the authors agreed to to a grammar review. > > > > /Loa > > > > On 2014-01-20 04:40, Venkatesan Mahalingam wrote: > >> ++Adrian and MIB doctors. > >> > >> On Sunday, January 19, 2014, Venkatesan Mahalingam > >> > > >> wrote: > >> > >> Hi All, > >> > >> As we have quite a few review comments from AD, we are addressing > >> them in the private mail thread below. > >> > >> >>I think you should discuss with your document shepherd whether to > >> release the > >> >>changes in batches as you go along, or wait for all the changes > >> in one go. > >> > >> *Loa:* How would you like to proceed? Shall we release the changes > >> in batches or all changes in one go? > >> > >> As some of the authors are in vacation now, could not spend much > >> time for discussing the comments. Hopefully, we will make this > >> document into good shape by end of this month. > >> > >> *Adrian: *Thanks for your response. We(Authors) shall discuss > >> further on your below comments and update you as early as possible. > >> > >> >>Is there a reason to have this discussion in private and missing > >> one of your > >> >>co-authors? > >> Nope. Tom's Juniper email was bouncing and later I forgot to add him > >> in the mail thread. It's my bad..;-) > >> > >> -Venkat. > >> > >> ---------- Forwarded message ---------- > >> From: *Adrian Farrel* >> 'cvml', 'adrian@olddog.co.uk');>> > >> Date: Sun, Jan 19, 2014 at 10:24 AM > >> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib > >> To: Venkatesan Mahalingam >> > > >> Cc: Sam Aldrin >> 'sam.aldrin@gmail.com');>>, Kannan Sampath >> > > >> > >> > >> Hello, > >> Sorry for the delay. > >> > >> Is there a reason to have this discussion in private and missing one > >> of your > >> co-authors? > >> Don't forget that you'll need to explain o the working group and > >> your document > >> shepherd what you have changed and why. > >> > >> I have edited out the points where we have full agreement. > >> > >> Thanks for the work so far. I think we have some more to do. > >> > >> I think you should discuss with your document shepherd whether to > >> release the > >> changes in batches as you go along, or wait for all the changes in > >> one go. > >> > >> Cheers, > >> Adrian > >> > >> > It would be nice if someone could do a pass on this document for > >> > English and format. It is not essential because the RFC Editor > >> will > >> > resolve these issues, but it is wise because the fewer changes > >> the RFC > >> > Editor makes, the less chance there is of an accidental error. > >> > VM>> OK. > >> > >> Does "OK" mean that you agree with me that it would be nice, but > >> that nothing > >> will happen? > >> > >> > I see a contradiction in > >> > > >> > In > >> > particular, it describes managed objects of Tunnels, Identifiers, > >> Label > >> > Switching Router and Textual conventions for Multiprotocol Label > >> > Switching (MPLS) based Transport Profile (TP). These MIB modules > >> extend > >> > the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP > >> > operations, so the MPLS-TP name is not included in the MIB module > >> name. > >> > > >> > Either the extensions are for MPLS-TP or they are not. Your > >> second > >> > sentence says they are for more general applicability, and I > >> agree with > >> > that. So why does the first sentence and the document title talk > >> about > >> > MPLS-TP? > >> > > >> > VM>> Per Loa suggestion, we kept the mpls-tp in the title > >> because we > >> > develop this MIB module as part of IETF MPLS-TP project. > >> > First sentence will be changed. > >> > >> I see the change and am now faced with "untraditional networks" > >> which I like > >> even less. > >> > >> I wish you could decide what this MIB module is for and describe > >> that. Note that > >> this problem runs through the document where you talk about objects > >> and tables > >> being for MPLS-TP tunnels, etc. > >> > >> > I think the Introduction would be made more useful and > >> relevant if it > >> > described the purpose and content of this document. Currently > >> it says > >> > what the existing documents don't do (although even that is > >> pretty > >> > vague). > >> > >> You added a few words per the Abstract, but you didn't really change > >> the text. > >> Can you say what function you are adding support for. That would > >> probably > >> address my concern. > >> > >> And you left in place... > >> > >> > The existing Multiprotocol Label Switching (MPLS) Traffic > >> Engineering > >> > (TE) Management Information Base (MIB) [RFC3812] and Generalized > >> > Multiprotocol Label Switching (GMPLS) Traffic Engineering > >> Management > >> > Information Base [RFC4802] do not support the transport network > >> > requirements of NON-IP based management and static bidirectional > >> > tunnels. > >> > >> ...which says what other documents don;t allow you to do, but not > >> what this > >> document does. > >> > >> Furthermore, I previously said... > >> > >> > There is also an implication here that this MIB module supports > >> non-IP > >> > based management. I looked but didn't see any description of how > >> to run > >> > SNMP in the absence of IP. > >> > >> And I don't see any change for this. > >> How does an SNMP MIB module support non-IP based management? > >> > >> > It goes on... > >> > > >> > These MIB modules should be used in conjunction with [RFC3812] > >> > and companion document [RFC3813] for MPLS-TP tunnel > >> configuration and > >> > management. > >> > > >> > What is an "MPLS-TP tunnel"? > >> > > >> > VM>> This document mainly focuses on static bi-directional > >> tunnel. > >> > We'll update the introduction section to provide more details. > >> > >> I think you mean tunnels that are not set up by signaling? > >> What does "mainly" mean? > >> > >> You now have... > >> > >> This document mainly focuses on static > >> bidirectional MIB modules that should be used in conjunction > >> with > >> [RFC3812] and companion document [RFC3813] for MPLS Transport > >> Profile > >> (MPLS-TP) path configuration and management. > >> > >> What is a "static bidirectional MIB module". > >> What is an "MPLS-TP path"? How does it differ from an MPLS path? > >> > >> > Section 4 might have been an opportunity to provide the > >> information I > >> > think is missing from the Introduction. But unfortunately it > >> repeats > >> > some of the text form the Introduction and then gives a very > >> scanty > >> > description of the purpose of the work. > >> > > >> > Here, however, I find the text > >> > > >> > As the existing MPLS- > >> > TE-STD-MIB is not sufficient to capture all the ch > >> > > From tnadeau@lucidvision.com Mon Jan 20 08:26:02 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F209E1A01C1 for ; Mon, 20 Jan 2014 08:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535] 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 wF5L46H6LiUG for ; Mon, 20 Jan 2014 08:25:59 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9A39E1A01A5 for ; Mon, 20 Jan 2014 08:25:58 -0800 (PST) Received: from [192.168.1.115] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 420F026BF224; Mon, 20 Jan 2014 11:25:58 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_1E1D798F-F9E3-4A8B-BBFD-DF3D7A21EF95"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <084201cf15c4$6c644e40$452ceac0$@olddog.co.uk> Date: Mon, 20 Jan 2014 11:25:57 -0500 Message-Id: <8512CF0E-FFF2-4ADC-BC6E-12031FBF0D76@lucidvision.com> References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> <52DCCF25.9010405@cisco.com> <084201cf15c4$6c644e40$452ceac0$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1827) Cc: Sam Aldrin , Kannan Sampath , Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org, Loa Andersson Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 16:26:02 -0000 --Apple-Mail=_1E1D798F-F9E3-4A8B-BBFD-DF3D7A21EF95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel = wrote: > What I think Loa is saying is "help!" >=20 > The MIB Doctor review was great and found a large number of issues = with the > document. > Yet, when the document reached the AD for review there were still a = significant > number of issues with the MIB modules. >=20 > I don't think that the MIB Doctor can be expected to review and = re-review every > document until it is perfect (they are welcome to, and we are = delighted when > they do, but they are human and they have day jobs), and I believe = that > sometimes it is simply not possible to find all issues in the first = review > because one set of problems obscure another set. >=20 > Loa has forwarded a mail taken from part way through the email thread. = A number > of issues with the ANS.1 have been fixed by now, and this particular = email was > edited down to remove the technical issues and just leave the = "political" ones. >=20 > FWIW I have no issue with the level of review given to this document = by the MIB > Doctor. I do have an issue with the level of quality of this document = as it came > from the WG to first the MIB Doctor and then to me. >=20 > It needs to be understood, IMHO, that people writing MIB modules are = supposed to > understand roughly what they are doing and to use the MIB doctors to = verify the > quality and catch a few missed issues. It is not the MIB Doctor's job = to provide > the ASN.1 for the authors! >=20 > Loa is (rightly) wondering how he can get this sort of document up to = quality > when the WG is not very interested, the level of MIB clue in the WG is = low, and > the MIB Doctors are not super-heroes with days or weeks of spare time. = I have no > answer to that question except "Why do we keep writing write-access = MIB > modules?" I have made my opinion very clear on this in the past, and in = the case of this MIB the same holds true: I think the read-write stuff = is a giant waste of time. I objected to adding write capability to this = draft when the issue came up. At the time I predicted that based on past = experience, that we would waste hours upon hours on getting the write = capabilities correct for what is in effect a very simple MIB module that = should have taken a couple of months to complete in read-only format. = Look where we are? Why don't we save ourselves a lot of time and effort = going and make this read-only? Its very clear that nearly no one in = operations land uses writable MIBs. Why does the IETF continue to waste = its time with this? The world has moved forward, so we should too. I will also point out something apropos to Loa's comment of a = lack of interest in reviewing the document that out of the 4 or 5 people = that have actually worked on it, I believe that only 1 wanted write = capability. I am not an MPLS WG chair, so I didn't call consensus, but = to me, that is not consensus to embark on making something writable thus = signing the WG/editors/reviewers/etc... up to take on a huge amount of = additional effort for what amounts to very, very little return. --Tom > Adrian >=20 >>> The working group, the authors and the mib-doctors have put in a >>> substantial amount of time and effort to get the document in shape. >>>=20 >>> Not being a MIB-expert the shepherd have relied heavily on the >>> MIB-doctors. A process that worked well in the past. >>>=20 >>> Three different versions were iterated between the MIB-doctors and >>> the authors and updated according the comments from the MIB-doctor. >>> This process ends by the MIB-doctor saying that it is OK to request >>> publication. >>>=20 >>> I'm a bit lost - but will try to work with authors and MIB-doctors = to >>> get the document in shape. >> I'm not sure I understand your email, or to be more precise, what you >> expect from the MIB doctor? >> I concluded that MIB doctors review was done on this document. >> = http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history >> Am I wrong? >>>=20 >>> Question to Adrian: Scanning through your comments I have the = impression >>> that the actual MIB-modules are more or less ok, but that the >>> informative text is what needs to be updated, right? >> I don't see any MIB related feedback in this email. >>=20 >> Regards, Benoit >>> I also notice that >>> the authors agreed to to a grammar review. >>>=20 >>> /Loa >>>=20 >>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >>>> ++Adrian and MIB doctors. >>>>=20 >>>> On Sunday, January 19, 2014, Venkatesan Mahalingam >>>> > > >>>> wrote: >>>>=20 >>>> Hi All, >>>>=20 >>>> As we have quite a few review comments from AD, we are = addressing >>>> them in the private mail thread below. >>>>=20 >>>>>> I think you should discuss with your document shepherd whether to >>>> release the >>>>>> changes in batches as you go along, or wait for all the changes >>>> in one go. >>>>=20 >>>> *Loa:* How would you like to proceed? Shall we release the = changes >>>> in batches or all changes in one go? >>>>=20 >>>> As some of the authors are in vacation now, could not spend much >>>> time for discussing the comments. Hopefully, we will make this >>>> document into good shape by end of this month. >>>>=20 >>>> *Adrian: *Thanks for your response. We(Authors) shall discuss >>>> further on your below comments and update you as early as = possible. >>>>=20 >>>>>> Is there a reason to have this discussion in private and missing >>>> one of your >>>>>> co-authors? >>>> Nope. Tom's Juniper email was bouncing and later I forgot to add = him >>>> in the mail thread. It's my bad..;-) >>>>=20 >>>> -Venkat. >>>>=20 >>>> ---------- Forwarded message ---------- >>>> From: *Adrian Farrel* >>> 'cvml', 'adrian@olddog.co.uk');>> >>>> Date: Sun, Jan 19, 2014 at 10:24 AM >>>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >>>> To: Venkatesan Mahalingam >>> > >>>> Cc: Sam Aldrin >>> 'sam.aldrin@gmail.com');>>, Kannan Sampath >>> > >>>>=20 >>>>=20 >>>> Hello, >>>> Sorry for the delay. >>>>=20 >>>> Is there a reason to have this discussion in private and missing = one >>>> of your >>>> co-authors? >>>> Don't forget that you'll need to explain o the working group and >>>> your document >>>> shepherd what you have changed and why. >>>>=20 >>>> I have edited out the points where we have full agreement. >>>>=20 >>>> Thanks for the work so far. I think we have some more to do. >>>>=20 >>>> I think you should discuss with your document shepherd whether = to >>>> release the >>>> changes in batches as you go along, or wait for all the changes = in >>>> one go. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>>> It would be nice if someone could do a pass on this document for >>>>> English and format. It is not essential because the RFC Editor >>>> will >>>>> resolve these issues, but it is wise because the fewer changes >>>> the RFC >>>>> Editor makes, the less chance there is of an accidental error. >>>>> VM>> OK. >>>>=20 >>>> Does "OK" mean that you agree with me that it would be nice, but >>>> that nothing >>>> will happen? >>>>=20 >>>>> I see a contradiction in >>>>>=20 >>>>> In >>>>> particular, it describes managed objects of Tunnels, Identifiers, >>>> Label >>>>> Switching Router and Textual conventions for Multiprotocol Label >>>>> Switching (MPLS) based Transport Profile (TP). These MIB modules >>>> extend >>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >>>>> operations, so the MPLS-TP name is not included in the MIB module >>>> name. >>>>>=20 >>>>> Either the extensions are for MPLS-TP or they are not. Your >>>> second >>>>> sentence says they are for more general applicability, and I >>>> agree with >>>>> that. So why does the first sentence and the document title talk >>>> about >>>>> MPLS-TP? >>>>>=20 >>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title >>>> because we >>>>> develop this MIB module as part of IETF MPLS-TP project. >>>>> First sentence will be changed. >>>>=20 >>>> I see the change and am now faced with "untraditional networks" >>>> which I like >>>> even less. >>>>=20 >>>> I wish you could decide what this MIB module is for and describe >>>> that. Note that >>>> this problem runs through the document where you talk about = objects >>>> and tables >>>> being for MPLS-TP tunnels, etc. >>>>=20 >>>>> I think the Introduction would be made more useful and >>>> relevant if it >>>>> described the purpose and content of this document. Currently >>>> it says >>>>> what the existing documents don't do (although even that is >>>> pretty >>>>> vague). >>>>=20 >>>> You added a few words per the Abstract, but you didn't really = change >>>> the text. >>>> Can you say what function you are adding support for. That would >>>> probably >>>> address my concern. >>>>=20 >>>> And you left in place... >>>>=20 >>>>> The existing Multiprotocol Label Switching (MPLS) Traffic >>>> Engineering >>>>> (TE) Management Information Base (MIB) [RFC3812] and Generalized >>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering >>>> Management >>>>> Information Base [RFC4802] do not support the transport network >>>>> requirements of NON-IP based management and static bidirectional >>>>> tunnels. >>>>=20 >>>> ...which says what other documents don;t allow you to do, but = not >>>> what this >>>> document does. >>>>=20 >>>> Furthermore, I previously said... >>>>=20 >>>>> There is also an implication here that this MIB module supports >>>> non-IP >>>>> based management. I looked but didn't see any description of how >>>> to run >>>>> SNMP in the absence of IP. >>>>=20 >>>> And I don't see any change for this. >>>> How does an SNMP MIB module support non-IP based management? >>>>=20 >>>>> It goes on... >>>>>=20 >>>>> These MIB modules should be used in conjunction with [RFC3812] >>>>> and companion document [RFC3813] for MPLS-TP tunnel >>>> configuration and >>>>> management. >>>>>=20 >>>>> What is an "MPLS-TP tunnel"? >>>>>=20 >>>>> VM>> This document mainly focuses on static bi-directional >>>> tunnel. >>>>> We'll update the introduction section to provide more details. >>>>=20 >>>> I think you mean tunnels that are not set up by signaling? >>>> What does "mainly" mean? >>>>=20 >>>> You now have... >>>>=20 >>>> This document mainly focuses on static >>>> bidirectional MIB modules that should be used in = conjunction >>>> with >>>> [RFC3812] and companion document [RFC3813] for MPLS = Transport >>>> Profile >>>> (MPLS-TP) path configuration and management. >>>>=20 >>>> What is a "static bidirectional MIB module". >>>> What is an "MPLS-TP path"? How does it differ from an MPLS path? >>>>=20 >>>>> Section 4 might have been an opportunity to provide the >>>> information I >>>>> think is missing from the Introduction. But unfortunately it >>>> repeats >>>>> some of the text form the Introduction and then gives a very >>>> scanty >>>>> description of the purpose of the work. >>>>>=20 >>>>> Here, however, I find the text >>>>>=20 >>>>> As the existing MPLS- >>>>> TE-STD-MIB is not sufficient to capture all the ch >>>>=20 >>>=20 >=20 >=20 --Apple-Mail=_1E1D798F-F9E3-4A8B-BBFD-DF3D7A21EF95 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3U4VAAoJEPcO+I7eiUJZhBsP/1bvs1FezphfW6qEZ+MifKXv WFmSsyYL0dLO0y6ODRUuXP98l2K4oKKeMVKk8XihG9B500sgc7B4AWnghgxQMRZ0 mROCDMdWZynNfj+Xr1rhpqWsaN8b3o+Afn3m700VSLyQHx2rmD5Kqbj2T0Mr9LG9 vluRAENaN4A/Nij12Ua/mDk2SrgQc0zORMLF8yqGaAf80kiZX1vxr49CWYJeBWWl rOIrU/u2ZknRggQ02G+VuBn/dTsIM34/CcYbs1OzNNo2LCw0EFkI3MObi4PwxprB YYl6jJfrFtiC0R29knoZLdukMRguAf24y5ms7T2ZxOfRZSVact1aQSSxJAhQhL8T CsE2oIzOl7JKQBN8i10rrO7q8ZTxC1+P1jnSjL5hRGSZz7ZX4epgx1Q7r56wqqlA mC699kpmOI50ZVU330s7VDxVpYen9VWqkI62Sdd7yrDWDlvPqFOKx+wRywvpAIhV D+jpR9ii9Gr3Ma7/qWVFVFpsJsT09yk8Bp06Q0MCuk9Y+zI8bLSmIG/y8U7FCUE2 a1N4mLxzst/8mTssY+w4GqjtG6w8tqdwPq0HLGnhtDJZSJVvzh2Fm1bF3d8v4BuQ AB/4DsIr+qTRS7t+oVn+AgvPr4WoW2wcjxdBASSd3hpNfsilm5tu04BYK+wptHY7 exQ20YyBs4gbN+8p8qEX =MD4Z -----END PGP SIGNATURE----- --Apple-Mail=_1E1D798F-F9E3-4A8B-BBFD-DF3D7A21EF95-- From bclaise@cisco.com Mon Jan 20 08:51:38 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A8B1A01D2 for ; Mon, 20 Jan 2014 08:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.436 X-Spam-Level: X-Spam-Status: No, score=-9.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 afGYiJPBwGDE for ; Mon, 20 Jan 2014 08:51:34 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0241A01C6 for ; Mon, 20 Jan 2014 08:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12371; q=dns/txt; s=iport; t=1390236694; x=1391446294; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mXXjOY9MpJvEGToQ4jSrhm/EtvfWLKUPLbD+TAnTSRk=; b=af6sf0cTQbx5OwOIiK1VCGo9WgVLh530hpxr1adiRg8rOAlMv1wtI88G xd/Vp0sTwg3etdIjaehqf9h1CSBCU9wXGfebAL2dwotA/bLAIS324xfAI 4DD14nwXtetzYOEWJqErhaZpsH9elVxX4S92TyPR2+pBPYnhTxM90jUwQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GAOxT3VKQ/khN/2dsb2JhbABZgws4tHWHHoEQFnSCJQEBAQQ4MwYIEAsOAwMBAgEJHgcPAhAlCQgGAQwBBQIBAYdtAxENvXsNhVYXjGuBMhACAU8HBoQyAQOWNoFsgTKFFYYWhTuDLjs X-IronPort-AV: E=Sophos;i="4.95,691,1384300800"; d="scan'208";a="3234065" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 20 Jan 2014 16:51:28 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0KGpRIl007410; Mon, 20 Jan 2014 16:51:27 GMT Message-ID: <52DD540F.80302@cisco.com> Date: Mon, 20 Jan 2014 17:51:27 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , Farrel Adrian References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> <52DCCF25.9010405@cisco.com> <084201cf15c4$6c644e40$452ceac0$@olddog.co.uk> <8512CF0E-FFF2-4ADC-BC6E-12031FBF0D76@lucidvision.com> In-Reply-To: <8512CF0E-FFF2-4ADC-BC6E-12031FBF0D76@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Aldrin , Kannan Sampath , "MIB Doctors \(E-mail\)" , Venkatesan Mahalingam , mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org, Loa Andersson Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 16:51:38 -0000 On 20/01/2014 17:25, Thomas Nadeau wrote: > On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel wrote: > >> What I think Loa is saying is "help!" >> >> The MIB Doctor review was great and found a large number of issues with the >> document. >> Yet, when the document reached the AD for review there were still a significant >> number of issues with the MIB modules. >> >> I don't think that the MIB Doctor can be expected to review and re-review every >> document until it is perfect (they are welcome to, and we are delighted when >> they do, but they are human and they have day jobs), and I believe that >> sometimes it is simply not possible to find all issues in the first review >> because one set of problems obscure another set. >> >> Loa has forwarded a mail taken from part way through the email thread. A number >> of issues with the ANS.1 have been fixed by now, and this particular email was >> edited down to remove the technical issues and just leave the "political" ones. >> >> FWIW I have no issue with the level of review given to this document by the MIB >> Doctor. I do have an issue with the level of quality of this document as it came >> from the WG to first the MIB Doctor and then to me. >> >> It needs to be understood, IMHO, that people writing MIB modules are supposed to >> understand roughly what they are doing and to use the MIB doctors to verify the >> quality and catch a few missed issues. It is not the MIB Doctor's job to provide >> the ASN.1 for the authors! >> >> Loa is (rightly) wondering how he can get this sort of document up to quality >> when the WG is not very interested, the level of MIB clue in the WG is low, and >> the MIB Doctors are not super-heroes with days or weeks of spare time. I have no >> answer to that question except "Why do we keep writing write-access MIB >> modules?" > I have made my opinion very clear on this in the past, and in the case of this MIB the same holds true: I think the read-write stuff is a giant waste of time. I objected to adding write capability to this draft when the issue came up. At the time I predicted that based on past experience, that we would waste hours upon hours on getting the write capabilities correct for what is in effect a very simple MIB module that should have taken a couple of months to complete in read-only format. Look where we are? Why don't we save ourselves a lot of time and effort going and make this read-only? Its very clear that nearly no one in operations land uses writable MIBs. Why does the IETF continue to waste its time with this? The world has moved forward, so we should too. Let me it clear. IMO, SNMPSet is dead. During one of our last Ciscolive show (a big event with thousands of participants), I went to most of my NMS partners, asking about SNMPset. None are using SNMPSet. The only exception is a proprietary OPS feature called IP SLA. Now, if one WG wants to have read-write, that's also fine with me. Regards, Benoit > > I will also point out something apropos to Loa's comment of a lack of interest in reviewing the document that out of the 4 or 5 people that have actually worked on it, I believe that only 1 wanted write capability. I am not an MPLS WG chair, so I didn't call consensus, but to me, that is not consensus to embark on making something writable thus signing the WG/editors/reviewers/etc... up to take on a huge amount of additional effort for what amounts to very, very little return. > > --Tom > > > > >> Adrian >> >>>> The working group, the authors and the mib-doctors have put in a >>>> substantial amount of time and effort to get the document in shape. >>>> >>>> Not being a MIB-expert the shepherd have relied heavily on the >>>> MIB-doctors. A process that worked well in the past. >>>> >>>> Three different versions were iterated between the MIB-doctors and >>>> the authors and updated according the comments from the MIB-doctor. >>>> This process ends by the MIB-doctor saying that it is OK to request >>>> publication. >>>> >>>> I'm a bit lost - but will try to work with authors and MIB-doctors to >>>> get the document in shape. >>> I'm not sure I understand your email, or to be more precise, what you >>> expect from the MIB doctor? >>> I concluded that MIB doctors review was done on this document. >>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history >>> Am I wrong? >>>> Question to Adrian: Scanning through your comments I have the impression >>>> that the actual MIB-modules are more or less ok, but that the >>>> informative text is what needs to be updated, right? >>> I don't see any MIB related feedback in this email. >>> >>> Regards, Benoit >>>> I also notice that >>>> the authors agreed to to a grammar review. >>>> >>>> /Loa >>>> >>>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >>>>> ++Adrian and MIB doctors. >>>>> >>>>> On Sunday, January 19, 2014, Venkatesan Mahalingam >>>>> >> > >>>>> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> As we have quite a few review comments from AD, we are addressing >>>>> them in the private mail thread below. >>>>> >>>>>>> I think you should discuss with your document shepherd whether to >>>>> release the >>>>>>> changes in batches as you go along, or wait for all the changes >>>>> in one go. >>>>> >>>>> *Loa:* How would you like to proceed? Shall we release the changes >>>>> in batches or all changes in one go? >>>>> >>>>> As some of the authors are in vacation now, could not spend much >>>>> time for discussing the comments. Hopefully, we will make this >>>>> document into good shape by end of this month. >>>>> >>>>> *Adrian: *Thanks for your response. We(Authors) shall discuss >>>>> further on your below comments and update you as early as possible. >>>>> >>>>>>> Is there a reason to have this discussion in private and missing >>>>> one of your >>>>>>> co-authors? >>>>> Nope. Tom's Juniper email was bouncing and later I forgot to add him >>>>> in the mail thread. It's my bad..;-) >>>>> >>>>> -Venkat. >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: *Adrian Farrel* >>>> 'cvml', 'adrian@olddog.co.uk');>> >>>>> Date: Sun, Jan 19, 2014 at 10:24 AM >>>>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >>>>> To: Venkatesan Mahalingam >>>> > >>>>> Cc: Sam Aldrin >>>> 'sam.aldrin@gmail.com');>>, Kannan Sampath >>>> > >>>>> >>>>> >>>>> Hello, >>>>> Sorry for the delay. >>>>> >>>>> Is there a reason to have this discussion in private and missing one >>>>> of your >>>>> co-authors? >>>>> Don't forget that you'll need to explain o the working group and >>>>> your document >>>>> shepherd what you have changed and why. >>>>> >>>>> I have edited out the points where we have full agreement. >>>>> >>>>> Thanks for the work so far. I think we have some more to do. >>>>> >>>>> I think you should discuss with your document shepherd whether to >>>>> release the >>>>> changes in batches as you go along, or wait for all the changes in >>>>> one go. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>>> It would be nice if someone could do a pass on this document for >>>>>> English and format. It is not essential because the RFC Editor >>>>> will >>>>>> resolve these issues, but it is wise because the fewer changes >>>>> the RFC >>>>>> Editor makes, the less chance there is of an accidental error. >>>>>> VM>> OK. >>>>> Does "OK" mean that you agree with me that it would be nice, but >>>>> that nothing >>>>> will happen? >>>>> >>>>>> I see a contradiction in >>>>>> >>>>>> In >>>>>> particular, it describes managed objects of Tunnels, Identifiers, >>>>> Label >>>>>> Switching Router and Textual conventions for Multiprotocol Label >>>>>> Switching (MPLS) based Transport Profile (TP). These MIB modules >>>>> extend >>>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >>>>>> operations, so the MPLS-TP name is not included in the MIB module >>>>> name. >>>>>> Either the extensions are for MPLS-TP or they are not. Your >>>>> second >>>>>> sentence says they are for more general applicability, and I >>>>> agree with >>>>>> that. So why does the first sentence and the document title talk >>>>> about >>>>>> MPLS-TP? >>>>>> >>>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title >>>>> because we >>>>>> develop this MIB module as part of IETF MPLS-TP project. >>>>>> First sentence will be changed. >>>>> I see the change and am now faced with "untraditional networks" >>>>> which I like >>>>> even less. >>>>> >>>>> I wish you could decide what this MIB module is for and describe >>>>> that. Note that >>>>> this problem runs through the document where you talk about objects >>>>> and tables >>>>> being for MPLS-TP tunnels, etc. >>>>> >>>>>> I think the Introduction would be made more useful and >>>>> relevant if it >>>>>> described the purpose and content of this document. Currently >>>>> it says >>>>>> what the existing documents don't do (although even that is >>>>> pretty >>>>>> vague). >>>>> You added a few words per the Abstract, but you didn't really change >>>>> the text. >>>>> Can you say what function you are adding support for. That would >>>>> probably >>>>> address my concern. >>>>> >>>>> And you left in place... >>>>> >>>>>> The existing Multiprotocol Label Switching (MPLS) Traffic >>>>> Engineering >>>>>> (TE) Management Information Base (MIB) [RFC3812] and Generalized >>>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering >>>>> Management >>>>>> Information Base [RFC4802] do not support the transport network >>>>>> requirements of NON-IP based management and static bidirectional >>>>>> tunnels. >>>>> ...which says what other documents don;t allow you to do, but not >>>>> what this >>>>> document does. >>>>> >>>>> Furthermore, I previously said... >>>>> >>>>>> There is also an implication here that this MIB module supports >>>>> non-IP >>>>>> based management. I looked but didn't see any description of how >>>>> to run >>>>>> SNMP in the absence of IP. >>>>> And I don't see any change for this. >>>>> How does an SNMP MIB module support non-IP based management? >>>>> >>>>>> It goes on... >>>>>> >>>>>> These MIB modules should be used in conjunction with [RFC3812] >>>>>> and companion document [RFC3813] for MPLS-TP tunnel >>>>> configuration and >>>>>> management. >>>>>> >>>>>> What is an "MPLS-TP tunnel"? >>>>>> >>>>>> VM>> This document mainly focuses on static bi-directional >>>>> tunnel. >>>>>> We'll update the introduction section to provide more details. >>>>> I think you mean tunnels that are not set up by signaling? >>>>> What does "mainly" mean? >>>>> >>>>> You now have... >>>>> >>>>> This document mainly focuses on static >>>>> bidirectional MIB modules that should be used in conjunction >>>>> with >>>>> [RFC3812] and companion document [RFC3813] for MPLS Transport >>>>> Profile >>>>> (MPLS-TP) path configuration and management. >>>>> >>>>> What is a "static bidirectional MIB module". >>>>> What is an "MPLS-TP path"? How does it differ from an MPLS path? >>>>> >>>>>> Section 4 might have been an opportunity to provide the >>>>> information I >>>>>> think is missing from the Introduction. But unfortunately it >>>>> repeats >>>>>> some of the text form the Introduction and then gives a very >>>>> scanty >>>>>> description of the purpose of the work. >>>>>> >>>>>> Here, however, I find the text >>>>>> >>>>>> As the existing MPLS- >>>>>> TE-STD-MIB is not sufficient to capture all the ch >> From bclaise@cisco.com Mon Jan 20 09:42:23 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E8F1A01B7 for ; Mon, 20 Jan 2014 09:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 QEb0a0hIbj6C for ; Mon, 20 Jan 2014 09:42:21 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 976D41A015E for ; Mon, 20 Jan 2014 09:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1422; q=dns/txt; s=iport; t=1390239742; x=1391449342; h=message-id:date:from:mime-version:to:cc:subject; bh=8nvLaAOAp+uJSvFVLT37lhFfHaNACaY6f215844lzx0=; b=CciNFNmHzpNxFR1AsGLM1kmFV2G/ntThPqcxi1evTxvu60Ki/FnXmF7C PbEw+ibwqz0jCH6mst9CPXMkL9Y3bfT5KkwbkVMvQShSwwte6Y5qr3XQG FRLt2URiwIV4sFEk3cjBqZYBbljZQwpq2QlJEqDoAeIn90e7h/Dji2XD8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAMte3VKQ/khM/2dsb2JhbABZgwu8TYEQFnSCHIEIAR4BHRYYAwIBAgFLDQEHAQGIAcNsF45/hD8EmCKGR4tRgy47 X-IronPort-AV: E=Sophos;i="4.95,691,1384300800"; d="scan'208,217";a="3905416" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 20 Jan 2014 17:42:21 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0KHgKbv001823; Mon, 20 Jan 2014 17:42:20 GMT Message-ID: <52DD5FFC.8070103@cisco.com> Date: Mon, 20 Jan 2014 18:42:20 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: multipart/alternative; boundary="------------050703020904050907050205" Cc: Adrian Farrel Subject: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:42:23 -0000 This is a multi-part message in MIME format. --------------050703020904050907050205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, In light of the recent MIB doctor discussion, it might be a valid question to ask, during a MIB doctors review: why is this MIB module read-write? Obviously, the goal is not influence the WG if there is consensus to do a read-write MIB module, but to make sure a WG doesn't produce a read-write (as opposed to read-only) MIB module _just _because it thought was necessary. Regards, Benoit --------------050703020904050907050205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

In light of the recent MIB doctor discussion, it might be a valid question to ask, during a MIB doctors review: why is this MIB module read-write?
Obviously, the goal is not influence the WG if there is consensus to do a read-write MIB module, but to make sure a WG doesn't produce a read-write (as opposed to read-only) MIB module just because it thought was necessary.

Regards, Benoit
--------------050703020904050907050205-- From dromasca@avaya.com Tue Jan 21 01:34:50 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED811A0102 for ; Tue, 21 Jan 2014 01:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535] 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 AaV2FwOzCv_R for ; Tue, 21 Jan 2014 01:34:46 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C56181A00A9 for ; Tue, 21 Jan 2014 01:34:45 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHANk+3lKHCzI1/2dsb2JhbABZgmohOFa0O4chgQ8WdIIlAQEBAQIBAQEBD1kDAw0HBgEGDwEDAwEBAQEKHSgGCxQJCQEEARIIGodPAwkIAQyLdZEwoHINhVYXjGuBMQEQAgEePoMegRQEljUBgx6FPYVuhTuBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,695,1384318800"; d="scan'208";a="45954067" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Jan 2014 04:34:44 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 21 Jan 2014 04:22:38 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0158.001; Tue, 21 Jan 2014 04:34:43 -0500 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "MIB Doctors (E-mail)" Thread-Topic: SNMPSet is dead? (was: RE: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib) Thread-Index: Ac8Wi/obzlHA4vkWQTyBlAe1hvQGKw== Date: Tue, 21 Jan 2014 09:34:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243D32C3@AZ-FFEXMB04.global.avaya.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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MIB-DOCTORS] SNMPSet is dead? (was: RE: AD review of draft-ietf-mpls-tp-te-mib) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:34:50 -0000 Hi, I trimmed the distribution list to MIB Doctors. Benoit - you wrote:=20 > Let me it clear. IMO, SNMPSet is dead. > During one of our last Ciscolive show (a big event with thousands of > participants), I went to most of my NMS partners, asking about SNMPset. > None are using SNMPSet. The only exception is a proprietary OPS feature > called IP SLA. > Now, if one WG wants to have read-write, that's also fine with me. >=20 > Regards, Benoit 'SNMPSet is dead' is a very crisp statement. I believe that it deserves a s= eparate discussion with a separate subject line. Maybe to start here (MIB D= octors) and be continued in OPSAREA. Maybe we need some guidance for people= writing management data models (MIB modules, YANG modules) and for operato= rs. I do not have such a crisp opinion (yet?). I do know that in other SDOs= like the IEEE 802 they develop MIB modules with read-write capabilities. M= aybe they need also some guidance, or maybe their environments are differen= t (more enterprise networks thus 'controlled environments'?). In any case I= would avoid drawing conclusions from one vendor environment, be it as big = and as respectable as it is. SNMP is used today if different operational en= vironments , not only in SP routers networks. If we reach consensus that 'S= NMPSet' is dead - do we have a viable alternative? Is NETCONF mature enough= ,understood well enough, with enough tools and YANG modules to be an alter= native? Or maybe we do not need an alternative and we give up interoperabil= ity for configuration operations?=20 I do not know the answers to these questions.=20 Regards, Dan > -----Original Message----- > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of > Benoit Claise > Sent: =E9=E5=ED=A0=E1 20 =E9=F0=E5=E0=F8 2014 18:51 > To: Thomas Nadeau; Farrel Adrian > Cc: Sam Aldrin; Kannan Sampath; MIB Doctors (E-mail); Venkatesan > Mahalingam; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-te- > mib@tools.ietf.org; Loa Andersson > Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib >=20 > On 20/01/2014 17:25, Thomas Nadeau wrote: > > On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel > wrote: > > > >> What I think Loa is saying is "help!" > >> > >> The MIB Doctor review was great and found a large number of issues > >> with the document. > >> Yet, when the document reached the AD for review there were still a > >> significant number of issues with the MIB modules. > >> > >> I don't think that the MIB Doctor can be expected to review and > >> re-review every document until it is perfect (they are welcome to, > >> and we are delighted when they do, but they are human and they have > >> day jobs), and I believe that sometimes it is simply not possible to > >> find all issues in the first review because one set of problems obscur= e > another set. > >> > >> Loa has forwarded a mail taken from part way through the email > >> thread. A number of issues with the ANS.1 have been fixed by now, and > >> this particular email was edited down to remove the technical issues a= nd > just leave the "political" ones. > >> > >> FWIW I have no issue with the level of review given to this document > >> by the MIB Doctor. I do have an issue with the level of quality of > >> this document as it came from the WG to first the MIB Doctor and then = to > me. > >> > >> It needs to be understood, IMHO, that people writing MIB modules are > >> supposed to understand roughly what they are doing and to use the MIB > >> doctors to verify the quality and catch a few missed issues. It is > >> not the MIB Doctor's job to provide the ASN.1 for the authors! > >> > >> Loa is (rightly) wondering how he can get this sort of document up to > >> quality when the WG is not very interested, the level of MIB clue in > >> the WG is low, and the MIB Doctors are not super-heroes with days or > >> weeks of spare time. I have no answer to that question except "Why do > >> we keep writing write-access MIB modules?" > > I have made my opinion very clear on this in the past, and in the case > of this MIB the same holds true: I think the read-write stuff is a giant = waste > of time. I objected to adding write capability to this draft when the iss= ue > came up. At the time I predicted that based on past experience, that we > would waste hours upon hours on getting the write capabilities correct fo= r > what is in effect a very simple MIB module that should have taken a coupl= e > of months to complete in read-only format. Look where we are? Why don't > we save ourselves a lot of time and effort going and make this read-only?= Its > very clear that nearly no one in operations land uses writable MIBs. Why > does the IETF continue to waste its time with this? The world has moved > forward, so we should too. > Let me it clear. IMO, SNMPSet is dead. > During one of our last Ciscolive show (a big event with thousands of > participants), I went to most of my NMS partners, asking about SNMPset. > None are using SNMPSet. The only exception is a proprietary OPS feature > called IP SLA. > Now, if one WG wants to have read-write, that's also fine with me. >=20 > Regards, Benoit > > > > I will also point out something apropos to Loa's comment of a lack of > interest in reviewing the document that out of the 4 or 5 people that hav= e > actually worked on it, I believe that only 1 wanted write capability. I a= m not > an MPLS WG chair, so I didn't call consensus, but to me, that is not cons= ensus > to embark on making something writable thus signing the > WG/editors/reviewers/etc... up to take on a huge amount of additional > effort for what amounts to very, very little return. > > > > --Tom > > > > > > > > > >> Adrian > >> > >>>> The working group, the authors and the mib-doctors have put in a > >>>> substantial amount of time and effort to get the document in shape. > >>>> > >>>> Not being a MIB-expert the shepherd have relied heavily on the > >>>> MIB-doctors. A process that worked well in the past. > >>>> > >>>> Three different versions were iterated between the MIB-doctors and > >>>> the authors and updated according the comments from the MIB- > doctor. > >>>> This process ends by the MIB-doctor saying that it is OK to request > >>>> publication. > >>>> > >>>> I'm a bit lost - but will try to work with authors and MIB-doctors > >>>> to get the document in shape. > >>> I'm not sure I understand your email, or to be more precise, what > >>> you expect from the MIB doctor? > >>> I concluded that MIB doctors review was done on this document. > >>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-his > >>> tory > >>> Am I wrong? > >>>> Question to Adrian: Scanning through your comments I have the > >>>> impression that the actual MIB-modules are more or less ok, but > >>>> that the informative text is what needs to be updated, right? > >>> I don't see any MIB related feedback in this email. > >>> > >>> Regards, Benoit > >>>> I also notice that > >>>> the authors agreed to to a grammar review. > >>>> > >>>> /Loa > >>>> > >>>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: > >>>>> ++Adrian and MIB doctors. > >>>>> > >>>>> On Sunday, January 19, 2014, Venkatesan Mahalingam > >>>>> >>> > > >>>>> wrote: > >>>>> > >>>>> Hi All, > >>>>> > >>>>> As we have quite a few review comments from AD, we are > addressing > >>>>> them in the private mail thread below. > >>>>> > >>>>>>> I think you should discuss with your document shepherd whether > >>>>>>> to > >>>>> release the > >>>>>>> changes in batches as you go along, or wait for all the changes > >>>>> in one go. > >>>>> > >>>>> *Loa:* How would you like to proceed? Shall we release the > changes > >>>>> in batches or all changes in one go? > >>>>> > >>>>> As some of the authors are in vacation now, could not spend muc= h > >>>>> time for discussing the comments. Hopefully, we will make this > >>>>> document into good shape by end of this month. > >>>>> > >>>>> *Adrian: *Thanks for your response. We(Authors) shall discuss > >>>>> further on your below comments and update you as early as > possible. > >>>>> > >>>>>>> Is there a reason to have this discussion in private and missing > >>>>> one of your > >>>>>>> co-authors? > >>>>> Nope. Tom's Juniper email was bouncing and later I forgot to ad= d > him > >>>>> in the mail thread. It's my bad..;-) > >>>>> > >>>>> -Venkat. > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: *Adrian Farrel* >>>>> 'cvml', 'adrian@olddog.co.uk');>> > >>>>> Date: Sun, Jan 19, 2014 at 10:24 AM > >>>>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib > >>>>> To: Venkatesan Mahalingam >>>>> > > >>>>> Cc: Sam Aldrin >>>>> 'sam.aldrin@gmail.com');>>, Kannan Sampath > >>>>> > > >>>>> > >>>>> > >>>>> Hello, > >>>>> Sorry for the delay. > >>>>> > >>>>> Is there a reason to have this discussion in private and missin= g one > >>>>> of your > >>>>> co-authors? > >>>>> Don't forget that you'll need to explain o the working group an= d > >>>>> your document > >>>>> shepherd what you have changed and why. > >>>>> > >>>>> I have edited out the points where we have full agreement. > >>>>> > >>>>> Thanks for the work so far. I think we have some more to do. > >>>>> > >>>>> I think you should discuss with your document shepherd whether = to > >>>>> release the > >>>>> changes in batches as you go along, or wait for all the changes= in > >>>>> one go. > >>>>> > >>>>> Cheers, > >>>>> Adrian > >>>>> > >>>>>> It would be nice if someone could do a pass on this document for > >>>>>> English and format. It is not essential because the RFC Editor > >>>>> will > >>>>>> resolve these issues, but it is wise because the fewer changes > >>>>> the RFC > >>>>>> Editor makes, the less chance there is of an accidental error. > >>>>>> VM>> OK. > >>>>> Does "OK" mean that you agree with me that it would be nice, bu= t > >>>>> that nothing > >>>>> will happen? > >>>>> > >>>>>> I see a contradiction in > >>>>>> > >>>>>> In > >>>>>> particular, it describes managed objects of Tunnels, Identifiers, > >>>>> Label > >>>>>> Switching Router and Textual conventions for Multiprotocol Label > >>>>>> Switching (MPLS) based Transport Profile (TP). These MIB modules > >>>>> extend > >>>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP > >>>>>> operations, so the MPLS-TP name is not included in the MIB module > >>>>> name. > >>>>>> Either the extensions are for MPLS-TP or they are not. Your > >>>>> second > >>>>>> sentence says they are for more general applicability, and I > >>>>> agree with > >>>>>> that. So why does the first sentence and the document title talk > >>>>> about > >>>>>> MPLS-TP? > >>>>>> > >>>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title > >>>>> because we > >>>>>> develop this MIB module as part of IETF MPLS-TP project. > >>>>>> First sentence will be changed. > >>>>> I see the change and am now faced with "untraditional networks" > >>>>> which I like > >>>>> even less. > >>>>> > >>>>> I wish you could decide what this MIB module is for and describ= e > >>>>> that. Note that > >>>>> this problem runs through the document where you talk about > objects > >>>>> and tables > >>>>> being for MPLS-TP tunnels, etc. > >>>>> > >>>>>> I think the Introduction would be made more useful and > >>>>> relevant if it > >>>>>> described the purpose and content of this document. Currently > >>>>> it says > >>>>>> what the existing documents don't do (although even that is > >>>>> pretty > >>>>>> vague). > >>>>> You added a few words per the Abstract, but you didn't really > change > >>>>> the text. > >>>>> Can you say what function you are adding support for. That woul= d > >>>>> probably > >>>>> address my concern. > >>>>> > >>>>> And you left in place... > >>>>> > >>>>>> The existing Multiprotocol Label Switching (MPLS) Traffic > >>>>> Engineering > >>>>>> (TE) Management Information Base (MIB) [RFC3812] and > Generalized > >>>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering > >>>>> Management > >>>>>> Information Base [RFC4802] do not support the transport network > >>>>>> requirements of NON-IP based management and static bidirectional > >>>>>> tunnels. > >>>>> ...which says what other documents don;t allow you to do, but n= ot > >>>>> what this > >>>>> document does. > >>>>> > >>>>> Furthermore, I previously said... > >>>>> > >>>>>> There is also an implication here that this MIB module supports > >>>>> non-IP > >>>>>> based management. I looked but didn't see any description of how > >>>>> to run > >>>>>> SNMP in the absence of IP. > >>>>> And I don't see any change for this. > >>>>> How does an SNMP MIB module support non-IP based > management? > >>>>> > >>>>>> It goes on... > >>>>>> > >>>>>> These MIB modules should be used in conjunction with [RFC3812] > >>>>>> and companion document [RFC3813] for MPLS-TP tunnel > >>>>> configuration and > >>>>>> management. > >>>>>> > >>>>>> What is an "MPLS-TP tunnel"? > >>>>>> > >>>>>> VM>> This document mainly focuses on static bi-directional > >>>>> tunnel. > >>>>>> We'll update the introduction section to provide more details. > >>>>> I think you mean tunnels that are not set up by signaling? > >>>>> What does "mainly" mean? > >>>>> > >>>>> You now have... > >>>>> > >>>>> This document mainly focuses on static > >>>>> bidirectional MIB modules that should be used in > >>>>> conjunction with > >>>>> [RFC3812] and companion document [RFC3813] for MPLS > Transport > >>>>> Profile > >>>>> (MPLS-TP) path configuration and management. > >>>>> > >>>>> What is a "static bidirectional MIB module". > >>>>> What is an "MPLS-TP path"? How does it differ from an MPLS path= ? > >>>>> > >>>>>> Section 4 might have been an opportunity to provide the > >>>>> information I > >>>>>> think is missing from the Introduction. But unfortunately it > >>>>> repeats > >>>>>> some of the text form the Introduction and then gives a very > >>>>> scanty > >>>>>> description of the purpose of the work. > >>>>>> > >>>>>> Here, however, I find the text > >>>>>> > >>>>>> As the existing MPLS- > >>>>>> TE-STD-MIB is not sufficient to capture all the ch > >> >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From j.schoenwaelder@jacobs-university.de Tue Jan 21 01:47:32 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070CF1A02B4 for ; Tue, 21 Jan 2014 01:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 jTkwoEtLEmAh for ; Tue, 21 Jan 2014 01:47:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C55181A0087 for ; Tue, 21 Jan 2014 01:47:30 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77E0C2005E; Tue, 21 Jan 2014 10:47:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xiYyL3t6QOsT; Tue, 21 Jan 2014 10:47:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7F1D20049; Tue, 21 Jan 2014 10:47:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 18AB42AC268C; Tue, 21 Jan 2014 10:47:26 +0100 (CET) Date: Tue, 21 Jan 2014 10:47:26 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20140121094726.GB47210@elstar.local> Mail-Followup-To: Benoit Claise , "MIB Doctors (E-mail)" , Adrian Farrel References: <52DD5FFC.8070103@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52DD5FFC.8070103@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" , Adrian Farrel Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:47:32 -0000 On Mon, Jan 20, 2014 at 06:42:20PM +0100, Benoit Claise wrote: > Dear all, > > In light of the recent MIB doctor discussion, it might be a valid > question to ask, during a MIB doctors review: why is this MIB module > read-write? > Obviously, the goal is not influence the WG if there is consensus to > do a read-write MIB module, but to make sure a WG doesn't produce a > read-write (as opposed to read-only) MIB module _just _because it > thought was necessary. > A couple of years ago, I wrote this: http://tools.ietf.org/html/draft-schoenw-opsawg-copspr-historic-00 The reaction to this was _very_ interesting and I gave up (and mind you that I think COPS-PR and SPPI never saw anything close in terms of the deployment to that of SNMP). Good luck with finding concensus that SNMP set is dead. ;-) /js PS: Is it time for draft-schoenw-opsawg-copspr-historic-01, now that 4 more years have passed? ;-) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Jan 21 01:54:24 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0191A02D2 for ; Tue, 21 Jan 2014 01:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 DX2SbDL1oO3B for ; Tue, 21 Jan 2014 01:54:23 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD571A02D3 for ; Tue, 21 Jan 2014 01:54:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIHAHtD3lLGmAcV/2dsb2JhbABWA4JqIThWtDyHIYEPFnSCJQEBAQEDAQEBD1wGBQwCAgIBBgINAQIBBAEBAQodBxsMCxQJCAIEAQ0FCBqHYwEMi3WRMKZVFwSOSiEQBwYLgxOBFASZVIU9iymDLYIq X-IronPort-AV: E=Sophos;i="4.95,695,1384318800"; d="scan'208";a="45955708" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Jan 2014 04:54:22 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 21 Jan 2014 04:44:19 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Tue, 21 Jan 2014 10:54:21 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "Benoit Claise" Thread-Topic: [MIB-DOCTORS] Why is this MIB module read-write? Thread-Index: AQHPFgb7ObD7bbLL6EGX+W7K2ioreJqO3sMAgAAR4aA= Date: Tue, 21 Jan 2014 09:54:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> In-Reply-To: <20140121094726.GB47210@elstar.local> 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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" , Adrian Farrel Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:54:24 -0000 Hi, Maybe the lesson to learn (at least at this stage) is that rather than prop= osing formal actions on the status of the documents we should be issuing gu= idance to developers of applications and to operators?=20 Regards, Dan > -----Original Message----- > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: =E9=E5=ED=A0=E2 21 =E9=F0=E5=E0=F8 2014 11:47 > To: Benoit Claise > Cc: MIB Doctors (E-mail); Adrian Farrel > Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? >=20 > On Mon, Jan 20, 2014 at 06:42:20PM +0100, Benoit Claise wrote: > > Dear all, > > > > In light of the recent MIB doctor discussion, it might be a valid > > question to ask, during a MIB doctors review: why is this MIB module > > read-write? > > Obviously, the goal is not influence the WG if there is consensus to > > do a read-write MIB module, but to make sure a WG doesn't produce a > > read-write (as opposed to read-only) MIB module _just _because it > > thought was necessary. > > >=20 > A couple of years ago, I wrote this: >=20 > http://tools.ietf.org/html/draft-schoenw-opsawg-copspr-historic-00 >=20 > The reaction to this was _very_ interesting and I gave up (and mind you t= hat I > think COPS-PR and SPPI never saw anything close in terms of the > deployment to that of SNMP). Good luck with finding concensus that SNMP > set is dead. ;-) >=20 > /js >=20 > PS: Is it time for draft-schoenw-opsawg-copspr-historic-01, now that 4 > more years have passed? ;-) >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Tue Jan 21 02:15:50 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA7E1A009D for ; Tue, 21 Jan 2014 02:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bXK6tZxs-MHE for ; Tue, 21 Jan 2014 02:15:49 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 132B71A0050 for ; Tue, 21 Jan 2014 02:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1311; q=dns/txt; s=iport; t=1390299349; x=1391508949; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=/eQ07YYq9Ko81mKvKdAyFl8Z7kRwEKZcBHglCYWsmGU=; b=WZ06jAMDxMCBxjcTQ2T4J6AyZnbqBbKyTBE3gDPzzuSMCbkhzmc/vwNd wfshgitk1/9z6SKFflUL82akiVi2Ih8zMjkcGrMyB/mShncWRXSy4s6xK /B1jVGZiD+YVZntttxqyKaZhgrkc6ShGEXhC0NABzYX8DzJHeM8Yubaud Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0HAOhH3lKQ/khM/2dsb2JhbABZgws4tRaHIYEPFnSCJQEBAQQ4QBELGAkWDwkDAgECAUUGAQwIAQGIAQ3DexePBoQ4AQOYIoEyhRWLUYMuOw X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208";a="3936752" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 21 Jan 2014 10:15:48 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0LAFllT029915; Tue, 21 Jan 2014 10:15:48 GMT Message-ID: <52DE48D3.7040602@cisco.com> Date: Tue, 21 Jan 2014 11:15:47 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" , Adrian Farrel References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> In-Reply-To: <20140121094726.GB47210@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 10:15:51 -0000 On 21/01/2014 10:47, Juergen Schoenwaelder wrote: > On Mon, Jan 20, 2014 at 06:42:20PM +0100, Benoit Claise wrote: >> Dear all, >> >> In light of the recent MIB doctor discussion, it might be a valid >> question to ask, during a MIB doctors review: why is this MIB module >> read-write? >> Obviously, the goal is not influence the WG if there is consensus to >> do a read-write MIB module, but to make sure a WG doesn't produce a >> read-write (as opposed to read-only) MIB module _just _because it >> thought was necessary. >> > A couple of years ago, I wrote this: > > http://tools.ietf.org/html/draft-schoenw-opsawg-copspr-historic-00 > > The reaction to this was _very_ interesting and I gave up (and mind > you that I think COPS-PR and SPPI never saw anything close in terms of > the deployment to that of SNMP). Good luck with finding concensus that > SNMP set is dead. ;-) Finding consensus takes time and is always difficult. However, a bold statement from the OPS AD to make the non OPS people think is cheap. Note that "is SNMPSet dead?" is an article title authored by Andy Bierman, maybe 10 years ago. I can't find it back. Regards, Benoit > > /js > > PS: Is it time for draft-schoenw-opsawg-copspr-historic-01, now that 4 > more years have passed? ;-) > From bclaise@cisco.com Tue Jan 21 02:17:04 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3985D1A0050 for ; Tue, 21 Jan 2014 02:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 JP2HF25mCv_e for ; Tue, 21 Jan 2014 02:17:02 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5900D1A00AB for ; Tue, 21 Jan 2014 02:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2075; q=dns/txt; s=iport; t=1390299422; x=1391509022; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hDWhuVku0pOAU7cPJXrbjKakJlo46bgQAST2uDv/jro=; b=GuEn1+2NReAMrcqMIo9EyqZ2eQhy+9I1xXDy2FUb9QZKqDJ8HLHZOduZ dO1+GZsJYftzbWF4lcKkU7XxBkr9ZcR+rX4X590D43duEXfz4OGXoPSnh wuFUK/2kV0bW1b9XIYcQ4HRiXQu8Amr9CY1SBHPOP0nIv0J66LWvc8dP6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAHAHZI3lKQ/khN/2dsb2JhbABWA4MLOLUWhyGBDxZ0giUBAQEEAQEBLwEFNgYEAQwCAgkCEAEEAQEBCRYIBwkDAgECAQkMHwkIBgEMAQUCAQGIAQ2LdbgGFwSOaxAHBguEJwEDmCKBMoUVi1GDLjs X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208";a="3267530" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2014 10:17:01 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LAGxOh027308; Tue, 21 Jan 2014 10:16:59 GMT Message-ID: <52DE491B.8070704@cisco.com> Date: Tue, 21 Jan 2014 11:16:59 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit Cc: "MIB Doctors \(E-mail\)" , Adrian Farrel Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 10:17:04 -0000 Dan, > Hi, > > Maybe the lesson to learn (at least at this stage) is that rather than proposing formal actions on the status of the documents we should be issuing guidance to developers of applications and to operators? Exactly. That's still high on my priority list, and I addressed that topic again at the last OPSAREA meeting. Regards, Benoit > Regards, > > Dan > > >> -----Original Message----- >> From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of >> Juergen Schoenwaelder >> Sent: éåí â 21 éðåàø 2014 11:47 >> To: Benoit Claise >> Cc: MIB Doctors (E-mail); Adrian Farrel >> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? >> >> On Mon, Jan 20, 2014 at 06:42:20PM +0100, Benoit Claise wrote: >>> Dear all, >>> >>> In light of the recent MIB doctor discussion, it might be a valid >>> question to ask, during a MIB doctors review: why is this MIB module >>> read-write? >>> Obviously, the goal is not influence the WG if there is consensus to >>> do a read-write MIB module, but to make sure a WG doesn't produce a >>> read-write (as opposed to read-only) MIB module _just _because it >>> thought was necessary. >>> >> A couple of years ago, I wrote this: >> >> http://tools.ietf.org/html/draft-schoenw-opsawg-copspr-historic-00 >> >> The reaction to this was _very_ interesting and I gave up (and mind you that I >> think COPS-PR and SPPI never saw anything close in terms of the >> deployment to that of SNMP). Good luck with finding concensus that SNMP >> set is dead. ;-) >> >> /js >> >> PS: Is it time for draft-schoenw-opsawg-copspr-historic-01, now that 4 >> more years have passed? ;-) >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > . > From tnadeau@lucidvision.com Tue Jan 21 05:51:56 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8461A00B8 for ; Tue, 21 Jan 2014 05:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535] 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 RWMwhbdFdGec for ; Tue, 21 Jan 2014 05:51:52 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 586811A0113 for ; Tue, 21 Jan 2014 05:51:52 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0FE7826C0788; Tue, 21 Jan 2014 08:51:52 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_67212CD0-011A-45E9-BFD1-8E5E12C8B0D5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243D32C3@AZ-FFEXMB04.global.avaya.com> Date: Tue, 21 Jan 2014 08:51:51 -0500 Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA243D32C3@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMPSet is dead? (was: RE: AD review of draft-ietf-mpls-tp-te-mib) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:51:56 -0000 --Apple-Mail=_67212CD0-011A-45E9-BFD1-8E5E12C8B0D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1255 I applaud Benoit for his very pragmatic statement. There are = very few operators that use SNMP set any longer. The cost-benefit for = the IETF to work on writable MIBs in has long past, yet we continue to = wrestle with making MIBs writable. Why? Isn't this why NetConf/Mod were = invented? We knew long ago that configuration was a mess at best with = SNMP, so we went off and built a better approach. Based on that, I'd = say there should be a pretty high bar to justify spending WG resources = that are already very minimal to begin with in the area of developing = SNMP MIBs, to work on making those MIBs writable for a scant few that = might use them in that manner.=20 --Tom > Hi, >=20 > I trimmed the distribution list to MIB Doctors. >=20 > Benoit - you wrote:=20 >=20 >> Let me it clear. IMO, SNMPSet is dead. >> During one of our last Ciscolive show (a big event with thousands of >> participants), I went to most of my NMS partners, asking about = SNMPset. >> None are using SNMPSet. The only exception is a proprietary OPS = feature >> called IP SLA. >> Now, if one WG wants to have read-write, that's also fine with me. >>=20 >> Regards, Benoit >=20 > 'SNMPSet is dead' is a very crisp statement. I believe that it = deserves a separate discussion with a separate subject line. Maybe to = start here (MIB Doctors) and be continued in OPSAREA. Maybe we need some = guidance for people writing management data models (MIB modules, YANG = modules) and for operators. I do not have such a crisp opinion (yet?). I = do know that in other SDOs like the IEEE 802 they develop MIB modules = with read-write capabilities. Maybe they need also some guidance, or = maybe their environments are different (more enterprise networks thus = 'controlled environments'?). In any case I would avoid drawing = conclusions from one vendor environment, be it as big and as respectable = as it is. SNMP is used today if different operational environments , not = only in SP routers networks. If we reach consensus that 'SNMPSet' is = dead - do we have a viable alternative? Is NETCONF mature enough = ,understood well enough, with enough tools and YANG modules to be an = alternative? Or maybe we do not need an alternative and we give up = interoperability for configuration operations?=20 >=20 > I do not know the answers to these questions.=20 >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of >> Benoit Claise >> Sent: =E9=E5=ED =E1 20 =E9=F0=E5=E0=F8 2014 18:51 >> To: Thomas Nadeau; Farrel Adrian >> Cc: Sam Aldrin; Kannan Sampath; MIB Doctors (E-mail); Venkatesan >> Mahalingam; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-te- >> mib@tools.ietf.org; Loa Andersson >> Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib >>=20 >> On 20/01/2014 17:25, Thomas Nadeau wrote: >>> On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel = >> wrote: >>>=20 >>>> What I think Loa is saying is "help!" >>>>=20 >>>> The MIB Doctor review was great and found a large number of issues >>>> with the document. >>>> Yet, when the document reached the AD for review there were still a >>>> significant number of issues with the MIB modules. >>>>=20 >>>> I don't think that the MIB Doctor can be expected to review and >>>> re-review every document until it is perfect (they are welcome to, >>>> and we are delighted when they do, but they are human and they have >>>> day jobs), and I believe that sometimes it is simply not possible = to >>>> find all issues in the first review because one set of problems = obscure >> another set. >>>>=20 >>>> Loa has forwarded a mail taken from part way through the email >>>> thread. A number of issues with the ANS.1 have been fixed by now, = and >>>> this particular email was edited down to remove the technical = issues and >> just leave the "political" ones. >>>>=20 >>>> FWIW I have no issue with the level of review given to this = document >>>> by the MIB Doctor. I do have an issue with the level of quality of >>>> this document as it came from the WG to first the MIB Doctor and = then to >> me. >>>>=20 >>>> It needs to be understood, IMHO, that people writing MIB modules = are >>>> supposed to understand roughly what they are doing and to use the = MIB >>>> doctors to verify the quality and catch a few missed issues. It is >>>> not the MIB Doctor's job to provide the ASN.1 for the authors! >>>>=20 >>>> Loa is (rightly) wondering how he can get this sort of document up = to >>>> quality when the WG is not very interested, the level of MIB clue = in >>>> the WG is low, and the MIB Doctors are not super-heroes with days = or >>>> weeks of spare time. I have no answer to that question except "Why = do >>>> we keep writing write-access MIB modules?" >>> I have made my opinion very clear on this in the past, and in = the case >> of this MIB the same holds true: I think the read-write stuff is a = giant waste >> of time. I objected to adding write capability to this draft when the = issue >> came up. At the time I predicted that based on past experience, that = we >> would waste hours upon hours on getting the write capabilities = correct for >> what is in effect a very simple MIB module that should have taken a = couple >> of months to complete in read-only format. Look where we are? Why = don't >> we save ourselves a lot of time and effort going and make this = read-only? Its >> very clear that nearly no one in operations land uses writable MIBs. = Why >> does the IETF continue to waste its time with this? The world has = moved >> forward, so we should too. >> Let me it clear. IMO, SNMPSet is dead. >> During one of our last Ciscolive show (a big event with thousands of >> participants), I went to most of my NMS partners, asking about = SNMPset. >> None are using SNMPSet. The only exception is a proprietary OPS = feature >> called IP SLA. >> Now, if one WG wants to have read-write, that's also fine with me. >>=20 >> Regards, Benoit >>>=20 >>> I will also point out something apropos to Loa's comment of a = lack of >> interest in reviewing the document that out of the 4 or 5 people that = have >> actually worked on it, I believe that only 1 wanted write capability. = I am not >> an MPLS WG chair, so I didn't call consensus, but to me, that is not = consensus >> to embark on making something writable thus signing the >> WG/editors/reviewers/etc... up to take on a huge amount of additional >> effort for what amounts to very, very little return. >>>=20 >>> --Tom >>>=20 >>>=20 >>>=20 >>>=20 >>>> Adrian >>>>=20 >>>>>> The working group, the authors and the mib-doctors have put in a >>>>>> substantial amount of time and effort to get the document in = shape. >>>>>>=20 >>>>>> Not being a MIB-expert the shepherd have relied heavily on the >>>>>> MIB-doctors. A process that worked well in the past. >>>>>>=20 >>>>>> Three different versions were iterated between the MIB-doctors = and >>>>>> the authors and updated according the comments from the MIB- >> doctor. >>>>>> This process ends by the MIB-doctor saying that it is OK to = request >>>>>> publication. >>>>>>=20 >>>>>> I'm a bit lost - but will try to work with authors and = MIB-doctors >>>>>> to get the document in shape. >>>>> I'm not sure I understand your email, or to be more precise, what >>>>> you expect from the MIB doctor? >>>>> I concluded that MIB doctors review was done on this document. >>>>> = http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-his >>>>> tory >>>>> Am I wrong? >>>>>> Question to Adrian: Scanning through your comments I have the >>>>>> impression that the actual MIB-modules are more or less ok, but >>>>>> that the informative text is what needs to be updated, right? >>>>> I don't see any MIB related feedback in this email. >>>>>=20 >>>>> Regards, Benoit >>>>>> I also notice that >>>>>> the authors agreed to to a grammar review. >>>>>>=20 >>>>>> /Loa >>>>>>=20 >>>>>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >>>>>>> ++Adrian and MIB doctors. >>>>>>>=20 >>>>>>> On Sunday, January 19, 2014, Venkatesan Mahalingam >>>>>>> >>>> > >>>>>>> wrote: >>>>>>>=20 >>>>>>> Hi All, >>>>>>>=20 >>>>>>> As we have quite a few review comments from AD, we are >> addressing >>>>>>> them in the private mail thread below. >>>>>>>=20 >>>>>>>>> I think you should discuss with your document shepherd whether >>>>>>>>> to >>>>>>> release the >>>>>>>>> changes in batches as you go along, or wait for all the = changes >>>>>>> in one go. >>>>>>>=20 >>>>>>> *Loa:* How would you like to proceed? Shall we release the >> changes >>>>>>> in batches or all changes in one go? >>>>>>>=20 >>>>>>> As some of the authors are in vacation now, could not spend = much >>>>>>> time for discussing the comments. Hopefully, we will make = this >>>>>>> document into good shape by end of this month. >>>>>>>=20 >>>>>>> *Adrian: *Thanks for your response. We(Authors) shall discuss >>>>>>> further on your below comments and update you as early as >> possible. >>>>>>>=20 >>>>>>>>> Is there a reason to have this discussion in private and = missing >>>>>>> one of your >>>>>>>>> co-authors? >>>>>>> Nope. Tom's Juniper email was bouncing and later I forgot to = add >> him >>>>>>> in the mail thread. It's my bad..;-) >>>>>>>=20 >>>>>>> -Venkat. >>>>>>>=20 >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: *Adrian Farrel* >>>>>> 'cvml', 'adrian@olddog.co.uk');>> >>>>>>> Date: Sun, Jan 19, 2014 at 10:24 AM >>>>>>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >>>>>>> To: Venkatesan Mahalingam >>>>>> > >>>>>>> Cc: Sam Aldrin >>>>>> 'sam.aldrin@gmail.com');>>, Kannan Sampath >> >>>>>> > >>>>>>>=20 >>>>>>>=20 >>>>>>> Hello, >>>>>>> Sorry for the delay. >>>>>>>=20 >>>>>>> Is there a reason to have this discussion in private and = missing one >>>>>>> of your >>>>>>> co-authors? >>>>>>> Don't forget that you'll need to explain o the working group = and >>>>>>> your document >>>>>>> shepherd what you have changed and why. >>>>>>>=20 >>>>>>> I have edited out the points where we have full agreement. >>>>>>>=20 >>>>>>> Thanks for the work so far. I think we have some more to do. >>>>>>>=20 >>>>>>> I think you should discuss with your document shepherd = whether to >>>>>>> release the >>>>>>> changes in batches as you go along, or wait for all the = changes in >>>>>>> one go. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Adrian >>>>>>>=20 >>>>>>>> It would be nice if someone could do a pass on this document = for >>>>>>>> English and format. It is not essential because the RFC Editor >>>>>>> will >>>>>>>> resolve these issues, but it is wise because the fewer changes >>>>>>> the RFC >>>>>>>> Editor makes, the less chance there is of an accidental error. >>>>>>>> VM>> OK. >>>>>>> Does "OK" mean that you agree with me that it would be nice, = but >>>>>>> that nothing >>>>>>> will happen? >>>>>>>=20 >>>>>>>> I see a contradiction in >>>>>>>>=20 >>>>>>>> In >>>>>>>> particular, it describes managed objects of Tunnels, = Identifiers, >>>>>>> Label >>>>>>>> Switching Router and Textual conventions for Multiprotocol = Label >>>>>>>> Switching (MPLS) based Transport Profile (TP). These MIB = modules >>>>>>> extend >>>>>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >>>>>>>> operations, so the MPLS-TP name is not included in the MIB = module >>>>>>> name. >>>>>>>> Either the extensions are for MPLS-TP or they are not. Your >>>>>>> second >>>>>>>> sentence says they are for more general applicability, and I >>>>>>> agree with >>>>>>>> that. So why does the first sentence and the document title = talk >>>>>>> about >>>>>>>> MPLS-TP? >>>>>>>>=20 >>>>>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title >>>>>>> because we >>>>>>>> develop this MIB module as part of IETF MPLS-TP project. >>>>>>>> First sentence will be changed. >>>>>>> I see the change and am now faced with "untraditional = networks" >>>>>>> which I like >>>>>>> even less. >>>>>>>=20 >>>>>>> I wish you could decide what this MIB module is for and = describe >>>>>>> that. Note that >>>>>>> this problem runs through the document where you talk about >> objects >>>>>>> and tables >>>>>>> being for MPLS-TP tunnels, etc. >>>>>>>=20 >>>>>>>> I think the Introduction would be made more useful and >>>>>>> relevant if it >>>>>>>> described the purpose and content of this document. Currently >>>>>>> it says >>>>>>>> what the existing documents don't do (although even that is >>>>>>> pretty >>>>>>>> vague). >>>>>>> You added a few words per the Abstract, but you didn't really >> change >>>>>>> the text. >>>>>>> Can you say what function you are adding support for. That = would >>>>>>> probably >>>>>>> address my concern. >>>>>>>=20 >>>>>>> And you left in place... >>>>>>>=20 >>>>>>>> The existing Multiprotocol Label Switching (MPLS) Traffic >>>>>>> Engineering >>>>>>>> (TE) Management Information Base (MIB) [RFC3812] and >> Generalized >>>>>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering >>>>>>> Management >>>>>>>> Information Base [RFC4802] do not support the transport network >>>>>>>> requirements of NON-IP based management and static = bidirectional >>>>>>>> tunnels. >>>>>>> ...which says what other documents don;t allow you to do, but = not >>>>>>> what this >>>>>>> document does. >>>>>>>=20 >>>>>>> Furthermore, I previously said... >>>>>>>=20 >>>>>>>> There is also an implication here that this MIB module supports >>>>>>> non-IP >>>>>>>> based management. I looked but didn't see any description of = how >>>>>>> to run >>>>>>>> SNMP in the absence of IP. >>>>>>> And I don't see any change for this. >>>>>>> How does an SNMP MIB module support non-IP based >> management? >>>>>>>=20 >>>>>>>> It goes on... >>>>>>>>=20 >>>>>>>> These MIB modules should be used in conjunction with [RFC3812] >>>>>>>> and companion document [RFC3813] for MPLS-TP tunnel >>>>>>> configuration and >>>>>>>> management. >>>>>>>>=20 >>>>>>>> What is an "MPLS-TP tunnel"? >>>>>>>>=20 >>>>>>>> VM>> This document mainly focuses on static bi-directional >>>>>>> tunnel. >>>>>>>> We'll update the introduction section to provide more details. >>>>>>> I think you mean tunnels that are not set up by signaling? >>>>>>> What does "mainly" mean? >>>>>>>=20 >>>>>>> You now have... >>>>>>>=20 >>>>>>> This document mainly focuses on static >>>>>>> bidirectional MIB modules that should be used in >>>>>>> conjunction with >>>>>>> [RFC3812] and companion document [RFC3813] for MPLS >> Transport >>>>>>> Profile >>>>>>> (MPLS-TP) path configuration and management. >>>>>>>=20 >>>>>>> What is a "static bidirectional MIB module". >>>>>>> What is an "MPLS-TP path"? How does it differ from an MPLS = path? >>>>>>>=20 >>>>>>>> Section 4 might have been an opportunity to provide the >>>>>>> information I >>>>>>>> think is missing from the Introduction. But unfortunately it >>>>>>> repeats >>>>>>>> some of the text form the Introduction and then gives a very >>>>>>> scanty >>>>>>>> description of the purpose of the work. >>>>>>>>=20 >>>>>>>> Here, however, I find the text >>>>>>>>=20 >>>>>>>> As the existing MPLS- >>>>>>>> TE-STD-MIB is not sufficient to capture all the ch >>>>=20 >>=20 >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors --Apple-Mail=_67212CD0-011A-45E9-BFD1-8E5E12C8B0D5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3nt3AAoJEPcO+I7eiUJZzxgQALa2kiwPK/nBxfAPtx1UkOd6 PKICjv6aR3Ijnd+sfZR5BoKR322QsLTPxXpjsLgIaWpf71AIaK0/eSgiGEM1/rqD FVCEBvRLalSwgag3WMywuePWvsk78oxtiulc0dmE7Ivl39D0yohCA7WRtAIMJgSY xWeSfsx641qV4cVaSN5ofxtcMGI9wzw0xY8G/PPlfbbyfv9MgNiEfDIfy66wae+i ZcBO37yXg7ksrKIGEnyha6So0KzG2oTBMp3z8FUlHNjs+xy+Vm9se+BZo0wPfV5v wUY4XHJn5U/wID9hQ90L7+h8GS3rtspxXYckik7H2RWWQAPQNqiajemCzxMRuWU1 29yy0fqqdXqlZzqICbwgAPFjl5V6FOakGwPsVx0coSZ43ClJD4VGyPj4dyhcCEDt /dyMmZdTlWdgdpXJH9Mlm1A1shupIP0nYH72E1EkG3qMa6XVMH0fzb4H7OBgvl4f fXOK1cq2gQCQR8wjrSGHUyRkoqinqAsAH0Er/VTnQ6ATMzXUkp7ZDrVnhVPMjzr0 sW9f5eDFsKhlmHsy3kcFTEyP2ZGaEguvy6YA+Y0wJxMoc50cbtaMqai/iKNY19ix iLmUwCZ6hoqwccPLP1KFsE1nTNdCoww3aIMDYvD+gSo29mrBST9MsmKUup9bbr44 fgjSXNykYJd1F+AFIWjX =wzFF -----END PGP SIGNATURE----- --Apple-Mail=_67212CD0-011A-45E9-BFD1-8E5E12C8B0D5-- From tnadeau@lucidvision.com Tue Jan 21 05:57:05 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774901A0125 for ; Tue, 21 Jan 2014 05:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 m1jLkfyc2w7G for ; Tue, 21 Jan 2014 05:57:03 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1801A0121 for ; Tue, 21 Jan 2014 05:57:03 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0E86926C07D8; Tue, 21 Jan 2014 08:57:03 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_151F138A-7726-48CA-94F0-4E70A2A9BE0F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> Date: Tue, 21 Jan 2014 08:57:01 -0500 Message-Id: References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , Farrel Adrian Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:57:05 -0000 --Apple-Mail=_151F138A-7726-48CA-94F0-4E70A2A9BE0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1255 Operators have already spoken, and I doubt they need guidance = from the IETF on this. If you do a poll of actual operations you will = find that very, very few have enabled SNMP writes in their networks.=20 I do agree that guidance needs to be issues to developers and = especially IETF WGs on this matter.=20 --Tom > Hi, >=20 > Maybe the lesson to learn (at least at this stage) is that rather than = proposing formal actions on the status of the documents we should be = issuing guidance to developers of applications and to operators?=20 >=20 > Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of >> Juergen Schoenwaelder >> Sent: =E9=E5=ED =E2 21 =E9=F0=E5=E0=F8 2014 11:47 >> To: Benoit Claise >> Cc: MIB Doctors (E-mail); Adrian Farrel >> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? >>=20 >> On Mon, Jan 20, 2014 at 06:42:20PM +0100, Benoit Claise wrote: >>> Dear all, >>>=20 >>> In light of the recent MIB doctor discussion, it might be a valid >>> question to ask, during a MIB doctors review: why is this MIB module >>> read-write? >>> Obviously, the goal is not influence the WG if there is consensus to >>> do a read-write MIB module, but to make sure a WG doesn't produce a >>> read-write (as opposed to read-only) MIB module _just _because it >>> thought was necessary. >>>=20 >>=20 >> A couple of years ago, I wrote this: >>=20 >> http://tools.ietf.org/html/draft-schoenw-opsawg-copspr-historic-00 >>=20 >> The reaction to this was _very_ interesting and I gave up (and mind = you that I >> think COPS-PR and SPPI never saw anything close in terms of the >> deployment to that of SNMP). Good luck with finding concensus that = SNMP >> set is dead. ;-) >>=20 >> /js >>=20 >> PS: Is it time for draft-schoenw-opsawg-copspr-historic-01, now that = 4 >> more years have passed? ;-) >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors --Apple-Mail=_151F138A-7726-48CA-94F0-4E70A2A9BE0F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3nyuAAoJEPcO+I7eiUJZhIEP/iGODjf99qSW0eHHGyb5ewaQ HgI+Krfii69R4vPEXM0epGm4n8b9n012oz8MX6kEbCnPqnOHXkg636wRHpQ83IKz 6oOZn3ETZTYPN6I0pUGiLMok2Pb1FedEwaPXBKgrGXZ6OHE/LwwwpjEc9ZHB19vU FmoVBYdgA1p1Z+TfjUn5A4+QMPWFZprzYFKn6+wpXlb1BPa8aXSNOLuohKqkXIQq BoJ22yehIAfOwNEVJx4rhNudkDsrbMoVNtf2HXTRh7VjL1uQSe75gBdcSylc2cCP DXkWU7LuzTyCSlerHGxa41CHkQmJEsI6/BLKpQ/Wkh9wOvXz5LNaANCDYw0JbQCr TztumLHK2yY8o0Yov7EGWzaPyCHnlG/S3kuLqlaYGlsKBSfdQaSlbR0F74yKBiL3 RJDltt6jfcykPppVvl/Cn8Rdn63G+87n5uzeqy1awpd5vXNzGY840QIt6LiUX+0W U3RdZrmWjuzhgezEHY/xOZFC9hSrzwfkUkXveKc9LU8UlhZLpOaqq6yWECo2/OYs auWOBzt78D3mRkrMT8o2AC9yEV7CfPHs73bYnUqLJh89k0gc347/05gee92XqY46 wpoWiVKFXygfemH4qYbs80i95xqjCy8p/GzhtOiDJb3RHpjpdpXkQoXDeXOd4LoR MuRQGsdjcT5+JwYZtOzl =z5WK -----END PGP SIGNATURE----- --Apple-Mail=_151F138A-7726-48CA-94F0-4E70A2A9BE0F-- From bertietf@bwijnen.net Tue Jan 21 06:49:13 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1E1A015D for ; Tue, 21 Jan 2014 06:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hXXoxp_ynFkx for ; Tue, 21 Jan 2014 06:49:11 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id E08201A014D for ; Tue, 21 Jan 2014 06:49:10 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5cdX-0004FW-D8; Tue, 21 Jan 2014 15:49:08 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W5cdX-00004x-94; Tue, 21 Jan 2014 15:49:07 +0100 Message-ID: <52DE88E3.7050301@bwijnen.net> Date: Tue, 21 Jan 2014 15:49:07 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA243D32C3@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e6386ca1d7368ea8ca74d39db46ec6c8 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMPSet is dead? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:49:13 -0000 Iirc, towards the end of my tenure as OPS AD I had already stopped asking for writable MIB modules. We never went as far as to tell a WG they could/should not do it, but iirc, from somewhere around end 2005 early 2006, we no longer required writable MIB modules. Bert On 21/01/14 14:51, Thomas Nadeau wrote: > I applaud Benoit for his very pragmatic statement. There are very few operators that use SNMP set any longer. The cost-benefit for the IETF to work on writable MIBs in has long past, yet we continue to wrestle with making MIBs writable. Why? Isn't this why NetConf/Mod were invented? We knew long ago that configuration was a mess at best with SNMP, so we went off and built a better approach. Based on that, I'd say there should be a pretty high bar to justify spending WG resources that are already very minimal to begin with in the area of developing SNMP MIBs, to work on making those MIBs writable for a scant few that might use them in that manner. > > --Tom From dromasca@avaya.com Tue Jan 21 07:05:34 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADC81A02BB for ; Tue, 21 Jan 2014 07:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 xvUf2peQZogp for ; Tue, 21 Jan 2014 07:05:33 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id F39671A0150 for ; Tue, 21 Jan 2014 07:05:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsLADWM3lKHCzI1/2dsb2JhbABagmohgQ60TocfgRAWdIIlAQEBAQMSZwwEAgEGAg0EBAEBAQodBzIUCQgCBAENBQgah2MBjC2RMKZtF45OMQcGgx6BFASfEYspgy2CKg X-IronPort-AV: E=Sophos;i="4.95,696,1384318800"; d="scan'208";a="45997068" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Jan 2014 10:05:32 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 21 Jan 2014 09:53:25 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Tue, 21 Jan 2014 16:05:31 +0100 From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Thomas Nadeau Thread-Topic: [MIB-DOCTORS] SNMPSet is dead? Thread-Index: AQHPFrfzKqE0srsS1EmpbQ+9XcG3xpqPRh2Q Date: Tue, 21 Jan 2014 15:05:30 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243D3BFA@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA243D32C3@AZ-FFEXMB04.global.avaya.com> <52DE88E3.7050301@bwijnen.net> In-Reply-To: <52DE88E3.7050301@bwijnen.net> 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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMPSet is dead? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:05:34 -0000 Saying 'we do not require writable MIB modules' is different from saying 'd= o not use writeable objects in MIB modules'.=20 Assuming that a working group reaches the conclusion that they need interop= erable configuration - what is the guidance provided by the OPS Area?=20 Regards, Dan > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: =E9=E5=ED=A0=E2 21 =E9=F0=E5=E0=F8 2014 16:49 > To: Thomas Nadeau; Romascanu, Dan (Dan) > Cc: MIB Doctors (E-mail) > Subject: Re: [MIB-DOCTORS] SNMPSet is dead? >=20 > Iris, towards the end of my tenure as OPS AD I had already stopped asking > for writable MIB modules. We never went as far as to tell a WG they > could/should not do it, but iirc, from somewhere around end 2005 early 20= 06, > we no longer required writable MIB modules. >=20 > Bert >=20 > On 21/01/14 14:51, Thomas Nadeau wrote: > > I applaud Benoit for his very pragmatic statement. There are very > few operators that use SNMP set any longer. The cost-benefit for the IETF= to > work on writable MIBs in has long past, yet we continue to wrestle with > making MIBs writable. Why? Isn't this why NetConf/Mod were invented? > We knew long ago that configuration was a mess at best with SNMP, so we > went off and built a better approach. Based on that, I'd say there shoul= d be a > pretty high bar to justify spending WG resources that are already very > minimal to begin with in the area of developing SNMP MIBs, to work on > making those MIBs writable for a scant few that might use them in that > manner. > > > > --Tom From dromasca@avaya.com Tue Jan 21 07:08:11 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A474C1A010D for ; Tue, 21 Jan 2014 07:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 IAh-f5XGb3Vs for ; Tue, 21 Jan 2014 07:08:10 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3521A02D7 for ; Tue, 21 Jan 2014 07:08:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoLADWM3lLGmAcV/2dsb2JhbABagmohgQ60TocfgRAWdIIlAQEBAQIBEig/BQcEAgEIDQEHDRQJBzIUEQIEDgUIGodbCAGdXaZtF45OMQeDJIEUBJ8RiymDLYIq X-IronPort-AV: E=Sophos;i="4.95,696,1384318800"; d="scan'208";a="45997597" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Jan 2014 10:08:08 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 21 Jan 2014 09:58:04 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Tue, 21 Jan 2014 16:08:06 +0100 From: "Romascanu, Dan (Dan)" To: Thomas Nadeau Thread-Topic: [MIB-DOCTORS] Why is this MIB module read-write? Thread-Index: AQHPFgb7ObD7bbLL6EGX+W7K2ioreJqO3sMAgAAR4aCAAJhwgP//v5xw Date: Tue, 21 Jan 2014 15:08:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: 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 Cc: "MIB Doctors \(E-mail\)" , Farrel Adrian Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:08:11 -0000 Hi Tom, This is exactly my point. I think that we should not only say 'do not do Se= ts using SNMP'. We should also say what to do instead.=20 Regards, Dan > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] .... > I do agree that guidance needs to be issues to developers and > especially IETF WGs on this matter. >=20 > --Tom >=20 From tnadeau@lucidvision.com Tue Jan 21 07:12:14 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070AB1A010D for ; Tue, 21 Jan 2014 07:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 35_4Wma-D2J7 for ; Tue, 21 Jan 2014 07:12:12 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 46DE01A0110 for ; Tue, 21 Jan 2014 07:12:12 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 880E826C0A47; Tue, 21 Jan 2014 10:12:11 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_E22975B2-E234-4AC9-A62F-DC81503DA8DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <52DE88E3.7050301@bwijnen.net> Date: Tue, 21 Jan 2014 10:12:10 -0500 Message-Id: <3866E6C0-2262-47DC-83B2-E8E3F079B68D@lucidvision.com> References: <9904FB1B0159DA42B0B887B7FA8119CA243D32C3@AZ-FFEXMB04.global.avaya.com> <52DE88E3.7050301@bwijnen.net> To: "Bert Wijnen (IETF)" X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMPSet is dead? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:12:14 -0000 --Apple-Mail=_E22975B2-E234-4AC9-A62F-DC81503DA8DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think the issue is of what you say Bert - its time to take = things a step further for the WGs to not only not require it, but to = perhaps actively discourage it. --Tom On Jan 21, 2014:9:49 AM, at 9:49 AM, Bert Wijnen (IETF) = wrote: > Iirc, towards the end of my tenure as OPS AD I had already stopped > asking for writable MIB modules. We never went as far as to tell a WG = they > could/should not do it, but iirc, from somewhere around end 2005 early = 2006, > we no longer required writable MIB modules. >=20 > Bert >=20 > On 21/01/14 14:51, Thomas Nadeau wrote: >> I applaud Benoit for his very pragmatic statement. There are = very few operators that use SNMP set any longer. The cost-benefit for = the IETF to work on writable MIBs in has long past, yet we continue to = wrestle with making MIBs writable. Why? Isn't this why NetConf/Mod were = invented? We knew long ago that configuration was a mess at best with = SNMP, so we went off and built a better approach. Based on that, I'd = say there should be a pretty high bar to justify spending WG resources = that are already very minimal to begin with in the area of developing = SNMP MIBs, to work on making those MIBs writable for a scant few that = might use them in that manner. >>=20 >> --Tom >=20 --Apple-Mail=_E22975B2-E234-4AC9-A62F-DC81503DA8DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3o5KAAoJEPcO+I7eiUJZu/cP/jOpUB6QGnPrCsY4TL+H4EUe yXItEDG8Khc+CXYma+Ll5BGgRFVMvgm/6Nw/Gh/hXN7XP+hrAIjSMlaShkkhBB2W fHlmgkKmuoGgdQUBrn/C2vcN7Ov5bjRpHPYr3nS68+b8JxZOvjdLIEBB4FIHW8SX jOewuwifQyDI40JHusu9tWeiA8yoN+8Brkt/H9ogzj6J5JKcZpcqXzaHCx1eV33i JE4QKUlKVajvm74Fy5WSrc8/oRj5kRFY3hqlBg6ynkHJ5kIhuliEurEFe+F/kXW9 d8YUyi/fXaPJKE/cq6CJxxfuu9g2YZY2iGsZwod/6LXZvnlWYyPVpi93eSKTV2mY FIGxgks7CE2mTOZ+pGhkbGR0CMcwxy5QxUEDzZufq1PSnjDAMomo4s7Of3RfL74q ijaTkzWfFWQXJkrwWXyvkKuls4FwMY/SncQIM1RQmUc/qy1oi/rS+Ae4R07hGtU7 +ijRXLb1l7z6cm0LTSRDrmrMvrns9NsPtrVuSyPe0X5FpQ7LpByODOPisZDYYXIr OtaLMr8/oqqIzqj+iW/you24bfYfFnNRT+MwbukEGw8gYeWJdQnklmexYptr4oKE 8DTEkwPY0n9ReiS4dwDOcMFEs+lz+upfltLVlTPVVx2GKu3vKOf+1+HQt1x5FzmB 7H5LoGHa3KYM64/OInWF =ajKC -----END PGP SIGNATURE----- --Apple-Mail=_E22975B2-E234-4AC9-A62F-DC81503DA8DB-- From tnadeau@lucidvision.com Tue Jan 21 07:14:26 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410211A0153 for ; Tue, 21 Jan 2014 07:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 5jTiAFEOsTXj for ; Tue, 21 Jan 2014 07:14:25 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C0A8C1A0144 for ; Tue, 21 Jan 2014 07:14:24 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 6D81426C0A6A; Tue, 21 Jan 2014 10:14:24 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_63721B84-ADE0-41DB-B769-EB4805D28D4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> Date: Tue, 21 Jan 2014 10:14:23 -0500 Message-Id: <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , Farrel Adrian Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:14:26 -0000 --Apple-Mail=_63721B84-ADE0-41DB-B769-EB4805D28D4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Agreed. Something like, "The OPS Area henceforth strongly = discourages the pursuit of writable SNMP MIBs by working groups except = in cases of clear utility and overwhelming consensus to do so. In all = other cases, we recommend the use of tools such as Netconf/Netmod for = configuration." --Tom > Hi Tom, >=20 > This is exactly my point. I think that we should not only say 'do not = do Sets using SNMP'. We should also say what to do instead.=20 >=20 > Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >=20 > .... >=20 >> I do agree that guidance needs to be issues to developers and >> especially IETF WGs on this matter. >>=20 >> --Tom >>=20 >=20 >=20 --Apple-Mail=_63721B84-ADE0-41DB-B769-EB4805D28D4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3o7PAAoJEPcO+I7eiUJZChkQAIKrTdsM47KroIYSyZCNSpdN l5THccRNnbuoY4/qMxVI9i9SfR0qQAMGF6UvaMKQirxAlhLFazZ2cyV2wX9DOrUx HyodzcK8fipIc/r0FXo0SI9yOv+6tUP57IGcUsA1kgpuzcd/XPYrA8z3a6unI5ge ZAiK6EIdKnTw8du/dCKt4ggMbHAxfo3G29FyxBUlJuQFJb0lA+FCshiE8kFeOpHs o2Xp4+U7a7Mj/8hNqjmWN6M15IqB9IaeDt6RscolE0f9B9tLUs00gigy8AnJ4lMs pC97wpG+0hKj/DZgxqFni5PWDRM246Z+Znzd0TTPBN5+GErFi4EYMvaA+YXYL34u iP+yY10Yp3YT8kjOQSWegwi756iHAgmZ2vOD91UhTjTSRipgP++so/a9uFm5eoUh CxRRlveoh0KqvS7xSnWnzIgL7l2G+OKSo0FVaU2Ir7cmWhFdcbI8WOM76rN10SFf Kr+Yq3+JVTBtOIRM7mSh9K5RZEHTjA6BsiKVhuMGOd/jbvPluIYwczsfnAkYvHU8 CYdtK3I4k+ZN6CcAPfIC/6ecAwVV+PfGmrvVh24iv+n5XHTa6KbyCjOdebS2x1jj jr9e1ef0RXh5QMGP9bYQZpH0o4Yi2KCSrrWMOFYGg+Qod+iAbcR1Id3TavMU05dP yO33XQeYlEbEkTsFp/xG =u2vy -----END PGP SIGNATURE----- --Apple-Mail=_63721B84-ADE0-41DB-B769-EB4805D28D4F-- From bertietf@bwijnen.net Tue Jan 21 07:29:57 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FED21A014A for ; Tue, 21 Jan 2014 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 M7NfivmoKmFs for ; Tue, 21 Jan 2014 07:29:54 -0800 (PST) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id EFA7B1A02BE for ; Tue, 21 Jan 2014 07:29:53 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5dGw-0002xW-LG; Tue, 21 Jan 2014 16:29:51 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W5dGw-0003hP-H5; Tue, 21 Jan 2014 16:29:50 +0100 Message-ID: <52DE926F.1030807@bwijnen.net> Date: Tue, 21 Jan 2014 16:29:51 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau References: <9904FB1B0159DA42B0B887B7FA8119CA243D32C3@AZ-FFEXMB04.global.avaya.com> <52DE88E3.7050301@bwijnen.net> <3866E6C0-2262-47DC-83B2-E8E3F079B68D@lucidvision.com> In-Reply-To: <3866E6C0-2262-47DC-83B2-E8E3F079B68D@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e53ac80816d078d53297166c788ccf19 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMPSet is dead? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:29:57 -0000 Yes I agree and am fine with that. I was just adding some infor for the record. We know for a long time already that SNMP set is not used much. Bert On 21/01/14 16:12, Thomas Nadeau wrote: > > I think the issue is of what you say Bert - its time to take things a step further for the WGs to not only not require it, but to perhaps actively discourage it. > > --Tom > > On Jan 21, 2014:9:49 AM, at 9:49 AM, Bert Wijnen (IETF) wrote: > >> Iirc, towards the end of my tenure as OPS AD I had already stopped >> asking for writable MIB modules. We never went as far as to tell a WG they >> could/should not do it, but iirc, from somewhere around end 2005 early 2006, >> we no longer required writable MIB modules. >> >> Bert >> >> On 21/01/14 14:51, Thomas Nadeau wrote: >>> I applaud Benoit for his very pragmatic statement. There are very few operators that use SNMP set any longer. The cost-benefit for the IETF to work on writable MIBs in has long past, yet we continue to wrestle with making MIBs writable. Why? Isn't this why NetConf/Mod were invented? We knew long ago that configuration was a mess at best with SNMP, so we went off and built a better approach. Based on that, I'd say there should be a pretty high bar to justify spending WG resources that are already very minimal to begin with in the area of developing SNMP MIBs, to work on making those MIBs writable for a scant few that might use them in that manner. >>> >>> --Tom >> > From bertietf@bwijnen.net Tue Jan 21 07:30:24 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6631A0194 for ; Tue, 21 Jan 2014 07:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dZxGc8Q6Cfqc for ; Tue, 21 Jan 2014 07:30:22 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 66BA31A014A for ; Tue, 21 Jan 2014 07:30:22 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5dHQ-0008Uo-F6; Tue, 21 Jan 2014 16:30:21 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W5dHQ-0003jF-BG; Tue, 21 Jan 2014 16:30:20 +0100 Message-ID: <52DE928D.1090909@bwijnen.net> Date: Tue, 21 Jan 2014 16:30:21 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , "Romascanu, Dan (Dan)" References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> In-Reply-To: <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44682060a38c3e5f12ded631c7f7f7af0 Cc: "MIB Doctors \(E-mail\)" , Farrel Adrian Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:30:24 -0000 sounds good to me Bert On 21/01/14 16:14, Thomas Nadeau wrote: > > Agreed. Something like, "The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs by working groups except in cases of clear utility and overwhelming consensus to do so. In all other cases, we recommend the use of tools such as Netconf/Netmod for configuration." > > --Tom > > >> Hi Tom, >> >> This is exactly my point. I think that we should not only say 'do not do Sets using SNMP'. We should also say what to do instead. >> >> Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> >> .... >> >>> I do agree that guidance needs to be issues to developers and >>> especially IETF WGs on this matter. >>> >>> --Tom >>> >> >> > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From macfaden@gmail.com Tue Jan 21 08:58:12 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DA21A02F2 for ; Tue, 21 Jan 2014 08:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 zT3nEQN4WNT0 for ; Tue, 21 Jan 2014 08:58:11 -0800 (PST) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8C38D1A01CE for ; Tue, 21 Jan 2014 08:58:11 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id nc12so7804052qeb.16 for ; Tue, 21 Jan 2014 08:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=x9RzAaukOy4ROYLvOUfLleNMbI+BG9ZqkI9FqlXg0xw=; b=ZHeDBezT1yU+jH9d9FrxSK8/sLHJRYngOsApRLnKMdGl+DhAhv2N8EoC47xoPxWoZT fKy8sfs+PoNJvZ/wulTLvoRHxoVQZZVGjY48iU25RSEKRl6a3CxLGmXrul/RzCFuTvaA v1XL54LqXy49vz9xs6ceXidUlocMO8fq3cVw0mXTp/JAwzwKJik6zFoXIR0LCgo27f/n 0nNg8k8JTDNTdiM2/vpJXKBh6frznkHDExnsJ17QOcW+28lAwmFyDQVHpXH0ZYQDTILQ kT2ZDDA8u0W6T2aorAWNgKX/do2PAzl3ZYO87V3XCPg5zVHGUVgL0HxlvGXRG8cnTg// riMA== MIME-Version: 1.0 X-Received: by 10.140.48.172 with SMTP id o41mr37107235qga.16.1390323491192; Tue, 21 Jan 2014 08:58:11 -0800 (PST) Sender: macfaden@gmail.com Received: by 10.229.177.197 with HTTP; Tue, 21 Jan 2014 08:58:11 -0800 (PST) Received: by 10.229.177.197 with HTTP; Tue, 21 Jan 2014 08:58:11 -0800 (PST) Date: Tue, 21 Jan 2014 08:58:11 -0800 X-Google-Sender-Auth: 3EdzvgsnlzBa1EOo-INoEkMU_Kw Message-ID: From: Michael MacFaden To: "MIB Doctors (E-mail)" Content-Type: multipart/alternative; boundary=001a11353500d0c4f404f07de938 Subject: Re: [MIB-DOCTORS] SNMPSet is dead? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 16:58:13 -0000 --001a11353500d0c4f404f07de938 Content-Type: text/plain; charset=ISO-8859-1 >From what I see, standardized configuration is not something that happens in IETF. Other organizations do that with measured success for a particular domain. These organizations tend to have clear scope and resources for testing and reporting compliance for a given vendor's product.. Examples include docsis and open networking foundation. That IETF builds one or more protocols to support configuration not withstanding, it remains to be seen if even these are ever adopted. So any policy to recommend what to use is understandable but not what implementers will look to in building product. Mike MacFaden --001a11353500d0c4f404f07de938 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

From what I see, standardized configuration is not something= that happens in IETF. Other organizations do that with measured success fo= r a particular domain.

These organizations tend to have=A0 clear scope and resource= s for testing and reporting compliance for a given vendor's product.. E= xamples include docsis and open networking foundation.

That IETF builds one or more protocols to support configurat= ion not withstanding, it remains to be seen if even these are ever adopted.=

So any policy to recommend what to use is understandable but= not what implementers will look to in building product.

Mike MacFaden

--001a11353500d0c4f404f07de938-- From chelliot@gmail.com Tue Jan 21 09:12:49 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6B1A02E7 for ; Tue, 21 Jan 2014 09:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 JT3InOZHnTsN for ; Tue, 21 Jan 2014 09:12:47 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 88ECE1A01C4 for ; Tue, 21 Jan 2014 09:12:47 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so6180314lbj.17 for ; Tue, 21 Jan 2014 09:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pJA0HFV2IR+dyw2v74f+LznbeKtcnQqn4fGg/+4wsFs=; b=H5rlVxGw5Puw4Cs7xUQVGRPoDpjR7VEyFWrd+/UzaDmVWufvmRdYUle8AYJbUJxP9D VHsjam9cwPZyiTC/qFth+P8beoUATjJhm32E51W3zuiGJUC+tYa7aqk1uF6tQh0y1Xrj 5Rhob7kRPY0MlIHQdr+s5k5V95OfPz7IIFPq2MYhN2N4dMgAGGBgI1zzECFA1lPwo2qy rVN2uROvT7xiKMn9PZMIFOkXd8jmF1bn6bZEOQPBvP7KpptHg4qDPFCUSo2TTH3rMvk/ OXkzglcocXJN6j6tnSok+p+qIgDrLPGPxs+9n2JDtJMyFiC/ygkb2EWL9sH5QLmI27YM L1YQ== MIME-Version: 1.0 X-Received: by 10.112.126.164 with SMTP id mz4mr1734076lbb.52.1390324366688; Tue, 21 Jan 2014 09:12:46 -0800 (PST) Sender: chelliot@gmail.com Received: by 10.114.71.34 with HTTP; Tue, 21 Jan 2014 09:12:46 -0800 (PST) In-Reply-To: References: Date: Tue, 21 Jan 2014 12:12:46 -0500 X-Google-Sender-Auth: LWkk3EGEf2rPPrvlfFBvigdiKUA Message-ID: From: Chris Elliott To: Michael MacFaden Content-Type: multipart/alternative; boundary=001a11c36e1cffc7ec04f07e1dad Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMPSet is dead? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chelliot@pobox.com List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:12:49 -0000 --001a11c36e1cffc7ec04f07e1dad Content-Type: text/plain; charset=ISO-8859-1 There are many uses of SNMP sets that have little or nothing to do with configuration. One of the problem with SNMP and SMI is that there isn't the notion of an action. Therefore, setting objects has been recruited to perform actions. A standards-based example is RMON, where SNMP sets are used to setup data collection and alarms. Cisco IOS has several SNMP settable objects that are used, including objects to reboot the device and download the device config. I use SNMP sets with objects in the CISCO-CONFIG-MIB to manage the Cisco devices in the IETF meeting networks--both to collect configs and to distribute changes (configlets). So SNMP set use isn't dead. SNMP set use to directly configure devices may be. And defining new read-write objects may be. Chris. On Tuesday, January 21, 2014, Michael MacFaden wrote: > From what I see, standardized configuration is not something that happens > in IETF. Other organizations do that with measured success for a particular > domain. > > These organizations tend to have clear scope and resources for testing > and reporting compliance for a given vendor's product.. Examples include > docsis and open networking foundation. > > That IETF builds one or more protocols to support configuration not > withstanding, it remains to be seen if even these are ever adopted. > > So any policy to recommend what to use is understandable but not what > implementers will look to in building product. > > Mike MacFaden > -- Chris Elliott chelliot@pobox.com --001a11c36e1cffc7ec04f07e1dad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are many uses of SNMP sets that have little or nothing=A0to do w= ith configuration.=A0One of the problem with SNMP and SMI is that there isn= 't the notion of an action. Therefore, setting objects=A0has been recru= ited to perform actions.

A standards-based example is RMON, where SNMP sets are = used to setup data collection and alarms.

Cisco IO= S has several SNMP settable=A0objects that are used, including objects=A0to= reboot the device and=A0download the device config.

I use SNMP sets with objects in the CISCO-CONFIG-MIB to= manage the Cisco devices in the IETF meeting networks--both to collect con= figs and to distribute changes (configlets).

So SN= MP set use isn't dead. SNMP set use to directly configure devices may b= e. And defining new read-write objects may be.

Chris.

On Tuesday, January 2= 1, 2014, Michael MacFaden <mrm@macfa= den.com> wrote:

From what I see, standardized configuration is not something= that happens in IETF. Other organizations do that with measured success fo= r a particular domain.

These organizations tend to have=A0 clear scope and resource= s for testing and reporting compliance for a given vendor's product.. E= xamples include docsis and open networking foundation.

That IETF builds one or more protocols to support configurat= ion not withstanding, it remains to be seen if even these are ever adopted.=

So any policy to recommend what to use is understandable but= not what implementers will look to in building product.

Mike MacFaden



--
Chris Elliott
chelliot@pobox.com

--001a11c36e1cffc7ec04f07e1dad-- From adrian@olddog.co.uk Tue Jan 21 09:32:22 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBB1A0164 for ; Tue, 21 Jan 2014 09:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 sGyoWrUQ-TVY for ; Tue, 21 Jan 2014 09:32:20 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B1B2B1A011D for ; Tue, 21 Jan 2014 09:32:19 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LHWE1A012997; Tue, 21 Jan 2014 17:32:15 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LHWBCe012983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jan 2014 17:32:13 GMT From: "Adrian Farrel" To: "'Bert Wijnen \(IETF\)'" , "'Thomas Nadeau'" , "'Romascanu, Dan \(Dan\)'" References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> In-Reply-To: <52DE928D.1090909@bwijnen.net> Date: Tue, 21 Jan 2014 17:32:13 -0000 Message-ID: <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEwrXAyK+Ki1CwZFR7+hxZNRxmWogG0C+dEAt2mkkAAjOOq2wFR3747AW/TSmIB1Go8e5t+mRcQ Content-Language: en-gb Cc: "'MIB Doctors \(E-mail\)'" Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:32:22 -0000 (speaking as not a MIB Doctor) I like that very much, thanks for the words Tom. Benoit, do you think this is a big enough issue that we should make it an IESG statement? Or do you just want to run it through the OPSAWG in some way? A > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: 21 January 2014 15:30 > To: Thomas Nadeau; Romascanu, Dan (Dan) > Cc: MIB Doctors (E-mail); Farrel Adrian > Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? > > sounds good to me > > Bert > > On 21/01/14 16:14, Thomas Nadeau wrote: > > > > Agreed. Something like, "The OPS Area henceforth strongly discourages > the pursuit of writable SNMP MIBs by working groups except in cases of clear > utility and overwhelming consensus to do so. In all other cases, we recommend > the use of tools such as Netconf/Netmod for configuration." > > > > --Tom > > > > > >> Hi Tom, > >> > >> This is exactly my point. I think that we should not only say 'do not do Sets > using SNMP'. We should also say what to do instead. > >> > >> Regards, > >> > >> Dan > >> > >> > >>> -----Original Message----- > >>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > >> > >> .... > >> > >>> I do agree that guidance needs to be issues to developers and > >>> especially IETF WGs on this matter. > >>> > >>> --Tom > >>> > >> > >> > > > > > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > From andy@yumaworks.com Tue Jan 21 09:43:32 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C614A1A02E8 for ; Tue, 21 Jan 2014 09:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 nggXjkwXSW7U for ; Tue, 21 Jan 2014 09:43:30 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9D40F1A01B1 for ; Tue, 21 Jan 2014 09:43:30 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so7485540qcy.1 for ; Tue, 21 Jan 2014 09:43:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YflWh+I3CsIHcmH7obTEdnGWTkY+5go8MzqbdLfIi4s=; b=Qv5qlZKYW3k1mIfoaXJD2/RaKs4AUdnH1cM4yTwB5krdTZTILvwmHvyiDGDClGRQO+ dQfuva0gSFiLkVBp22n4sVinmaVh6uJdSS+8Uz6YUePF/bbLE3JoQEeQImnI+kdZeKJW hLKxD2go5BTLDw5BKxFGfnH0L22SD2AmUKQQt0XbKgpGgHNSUWqoX7jC/8jxwaPJ6ILF qWxGYKiitWCxwCBYNIaT/YyHW3Qv+cNozva3abZ3MC4whvpo+UKn7QdTjeQDd3FsZJzX 1wCMdr+eqVFaXhQm4vgDynMfABJb/l25zNFFy7WUeF6Ne6/mw546HuB2s1yCwYy4rjg6 Q2oQ== X-Gm-Message-State: ALoCoQloyZ9xgF9z+CnJz1GwPEz7p3HEk48FufQ5t76Hy/TpQk7B5U1xYdXt0a/ptE1aNP9LMmBc MIME-Version: 1.0 X-Received: by 10.140.92.65 with SMTP id a59mr36802198qge.34.1390326209944; Tue, 21 Jan 2014 09:43:29 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 21 Jan 2014 09:43:29 -0800 (PST) In-Reply-To: References: Date: Tue, 21 Jan 2014 09:43:29 -0800 Message-ID: From: Andy Bierman To: Chris Elliott Content-Type: multipart/alternative; boundary=001a113ab29ee19af104f07e8b81 Cc: Michael MacFaden , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMPSet is dead? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:43:33 -0000 --001a113ab29ee19af104f07e8b81 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 21, 2014 at 9:12 AM, Chris Elliott wrote: > There are many uses of SNMP sets that have little or nothing to do with > configuration. One of the problem with SNMP and SMI is that there isn't the > notion of an action. Therefore, setting objects has been recruited to > perform actions. > > A standards-based example is RMON, where SNMP sets are used to setup data > collection and alarms. > > My group at Cisco wrote the RMON agent code. I uses the CLI to configure RMON for my testing though. > Cisco IOS has several SNMP settable objects that are used, including > objects to reboot the device and download the device config. > > I use SNMP sets with objects in the CISCO-CONFIG-MIB to manage the Cisco > devices in the IETF meeting networks--both to collect configs and to > distribute changes (configlets). > > So SNMP set use isn't dead. SNMP set use to directly configure devices may > be. And defining new read-write objects may be. > > I agree. The complexity of the data model and the use cases should determine if a writable MIB module is a good idea or not. I remember bugging Bert and others for about 2 years to even consider an XML alternative. (NETCONF was originally called XMLCONF). My experience implementing RMON2 server code and standardizing really complicated RMON MIBs convinced me that we had passed the upper-bound of the inherent complexity limits of SNMP/SMIv2. The CLI had built-in constraints that simplified implementation. SNMP had an arbitrary set of POKE operations that had to be somehow converted to a high-level transaction model. Operators were not asking to do N arbitrary partial edit operations at once, so this requirement in SNMP proved to be counter-productive. Chris. > > Andy > On Tuesday, January 21, 2014, Michael MacFaden wrote: > >> From what I see, standardized configuration is not something that happens >> in IETF. Other organizations do that with measured success for a particular >> domain. >> >> These organizations tend to have clear scope and resources for testing >> and reporting compliance for a given vendor's product.. Examples include >> docsis and open networking foundation. >> >> That IETF builds one or more protocols to support configuration not >> withstanding, it remains to be seen if even these are ever adopted. >> >> So any policy to recommend what to use is understandable but not what >> implementers will look to in building product. >> >> Mike MacFaden >> > > > -- > Chris Elliott > chelliot@pobox.com > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > --001a113ab29ee19af104f07e8b81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 21, 2014 at 9:12 AM, Chris Elliott &l= t;chelliot@pobox.co= m> wrote:
There are many uses of SNMP sets that h= ave little or nothing=A0to do with configuration.=A0One of the problem with= SNMP and SMI is that there isn't the notion of an action. Therefore, s= etting objects=A0has been recruited to perform actions.

A standards-based example is RMON, where SNMP sets are = used to setup data collection and alarms.

=

My group at Cisco wrote the RMON agent code.
I uses the CLI to configure RMON for my testing though.

=
=A0
Cisco IO= S has several SNMP settable=A0objects that are used, including objects=A0to= reboot the device and=A0download the device config.

I use SNMP sets with objects in the CISCO-CONFIG-MIB to= manage the Cisco devices in the IETF meeting networks--both to collect con= figs and to distribute changes (configlets).

So SNMP set use isn't dead. SNMP set use to directly configure devices = may be. And defining new read-write objects may be.


I agree. =A0The complexity = of the data model and the use cases should determine
if a writabl= e MIB module is a good idea or not.

I remember bug= ging Bert and others for about 2 years to even consider
an XML alternative. (NETCONF was originally called XMLCONF).
My experience implementing RMON2 server code and standardizing
r= eally complicated RMON MIBs convinced me that we had passed
the u= pper-bound of the inherent complexity limits of SNMP/SMIv2.

The CLI had built-in constraints that simplified implem= entation.
SNMP had an arbitrary set of POKE operations that had t= o be
somehow converted to a high-level transaction model.
Operators were not asking to do N arbitrary partial edit operations at= once,
so this requirement in SNMP proved to be counter-productiv= e.


Chris.

<= br>

Andy
=A0
On Tuesday, January 21, 2014, Michael MacFaden <mrm@macfaden.com> wrote:

From what I see, standardized configuration is not something= that happens in IETF. Other organizations do that with measured success fo= r a particular domain.

These organizations tend to have=A0 clear scope and resource= s for testing and reporting compliance for a given vendor's product.. E= xamples include docsis and open networking foundation.

That IETF builds one or more protocols to support configurat= ion not withstanding, it remains to be seen if even these are ever adopted.=

So any policy to recommend what to use is understandable but= not what implementers will look to in building product.

Mike MacFaden



--
Chris Elliott
chelliot@pobox.com


_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


--001a113ab29ee19af104f07e8b81-- From tnadeau@lucidvision.com Tue Jan 21 12:52:47 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939B01A01D1; Tue, 21 Jan 2014 12:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.535] 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 8LU5CuACcfji; Tue, 21 Jan 2014 12:52:41 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6400A1A0168; Tue, 21 Jan 2014 12:52:40 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9DC9D26C166B; Tue, 21 Jan 2014 15:52:39 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> Date: Tue, 21 Jan 2014 15:52:38 -0500 To: "MIB Doctors (E-mail)" , eman mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:52:47 -0000 --Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I reviewed this draft as part of the MIB Doctor review on = Tuesday, January 21, 2014. My comments inline begin with TOM: General Comments on the draft: 1) There are a number of warnings in the id-nits run. Please check = and correct these. 2) I found a number of references inside of DESCRIPTION clauses. = Remember that once the MIB is stripped out of this draft, those = references have no meaning. Please either add a Reference clause below, = or use an RFC/IEEE number that can easily be found. Please go through = every place where there is a reference in a DESCRIPTION clause and make = this correction as I will not comment on each and every one. 3) I generally like to include a comment after each MIB in the = IMPORTS clause stating which RFC it comes from. It is a good habit since = not all MIB modules are easily found for compilation. 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules = under transmission, rather than under the single OID energyMIB. These = modules still use the older approach, so please correct them. 5) Here is the output from smilint on each of the modules. I do not = have access to smicng, so this is the best I could do for compilation. = As you can see there are a number of nits that are found that should be = corrected such as importing values that are unused. Please fix these.=20 IANA-ENERGY-RELATION-MIB: [server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 = ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB = ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB ./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' = is already loaded, aborting parser on this file ./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be = imported from module `SNMPv2-SMI' ./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: = identifier `snmpEngineID' differs from `SnmpEngineID' only in case ./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous = definition of `SnmpEngineID' ./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used [server:libsmi-0.4.8/mibs/ietf] tnadeau%=20 ENERGY-OBJECT-CONTEXT-MIB: [server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 = ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB = ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB = ./ENERGY-OBJECT-CONTEXT-MIB ./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' = is already loaded, aborting parser on this file ./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be = imported from module `SNMPv2-SMI' ./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: = identifier `snmpEngineID' differs from `SnmpEngineID' only in case ./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous = definition of `SnmpEngineID' ./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-CONTEXT-MIB:79: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./ENERGY-OBJECT-CONTEXT-MIB:6: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-CONTEXT-MIB:9: [5] {import-unused} warning: identifier = `TruthValue' imported from module `SNMPv2-TC' is never used [server:libsmi-0.4.8/mibs/ietf] tnadeau%=20 Network Working Group J. Parello=20 Internet-Draft B. Claise=20 Intended Status: Standards Track Mouli Chandramouli=20 Expires: June 13, 2014 Cisco Systems, Inc.=20 December 13, 2013 =20= =20 =20 =20 Energy Object Context MIB =20 draft-ietf-eman-energy-aware-mib-13=20 Status of this Memo=20 This Internet-Draft is submitted to IETF in full conformance=20 with the provisions of BCP 78 and BCP 79. =20 =20 Internet-Drafts are working documents of the Internet=20 Engineering Task Force (IETF), its areas, and its working=20 groups. Note that other groups may also distribute working=20 documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20= months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work=20= in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20= http://www.ietf.org/shadow.html=20 =20 This Internet-Draft will expire on June 13, 2014. = =20 =20 Expires June 13, 2014 [Page 1]=20= =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Copyright Notice=20 =20 Copyright (c) 2012 IETF Trust and the persons identified as the=20= document authors. All rights reserved.=20 =20 This document is subject to BCP 78 and the IETF Trust's Legal=20 Provisions Relating to IETF Documents=20 (http://trustee.ietf.org/license-info) in effect on the date of=20= publication of this document. Please review these documents=20 carefully, as they describe your rights and restrictions with=20 respect to this document. Code Components extracted from this=20 document must include Simplified BSD License text as described=20= in Section 4.e of the Trust Legal Provisions and are provided=20 without warranty as described in the Simplified BSD License.=20 =20 =20 Abstract=20 This document defines a subset of a Management Information Base=20= (MIB) for energy management of devices. The module addresses=20 device identification, context information, and the=20 relationships between reporting devices, remote devices, and=20 monitoring devices.=20 =20 Conventions used in this document=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=20 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT=20 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to=20 be interpreted as described in RFC 2119 [RFC2119].=20 =20 =20 =20 Table of Contents=20 =20 1. Introduction............................................... 3=20= 1.1. Energy Management Document Overview....................3=20= 2. The Internet-Standard Management Framework................. 4=20= 3. Requirements and Use Cases................................. 4=20= 4. Terminology................................................ 4=20= 5. Architecture Concepts Applied to the MIB Module............ 6=20= 5.1 Energy Object Identification............................8=20= 5.2 Energy Object Context...................................9=20= 5.3 Links to Other Identifiers.............................10=20= 5.4 Energy Object Relationships............................11=20= 5.5 Energy Object Identity Persistence.....................12=20= 6. MIB Definitions........................................... 12=20= =20 =20 Expires June 13, 2014 [Page 2]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 7. Implementation Status..................................... 27=20= 8. Security Considerations................................... 28=20= 9. IANA Considerations....................................... 29=20= 10. Acknowledgement.......................................... 29=20= 11. References............................................... 30=20= 11.1. Normative References.................................30=20= 11.2. Informative References...............................31=20= =20 =20 1. Introduction=20 The EMAN standards provide a specification for Energy=20 Management. This document defines a subset of a Management=20 Information Base (MIB) for use with network management protocols=20= for Energy monitoring of network devices and devices attached to=20= the network and possibly extending to devices in the industrial=20= automation setting with a network interface. =20 =20 The focus of the MIB module specified in this document is on the=20= identification of Energy Objects and reporting the context and=20= relationships of Energy Objects as defined in [EMAN-FMWK]. The=20= module addresses Energy Object Identification, Energy Object=20 Context, and Energy Object Relationships.=20 =20 =20 1.1. Energy Management Document Overview=20 This document specifies the Energy Object Context (ENERGY- OBJECT-CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY- RELATION-MIB) modules. The Energy Object Context MIB module=20 specifies MIB objects for identification of Energy Objects, and=20= reporting context and relationship of an Energy Object. The IANA=20= Energy Relationship MIB module specifies the first version of=20 the IANA-maintained definitions of relationships between Energy=20= Objects.=20 =20 This document is based on the Energy Management Framework [EMAN- FMWK] and meets the requirements on identification of Energy=20 Objects and their context and relationships as specified in the=20= Energy Management requirements [RFC6988].=20 =20 A second MIB module required by the [EMAN-FMWK], the Power and=20= Energy Monitoring MIB [EMAN-MON-MIB], monitors the Energy=20 Objects for Power States, for the Power and Energy consumption.=20= Power State monitoring includes: retrieving Power States, Power=20= State properties, current Power State, Power State transitions,=20= and Power State statistics. In addition, this MIB module=20 =20 =20 Expires June 13, 2014 [Page 3]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 provides the Power Characteristics properties of the Power and=20= Energy, along with optional characteristics.=20 =20 The applicability statement document [EMAN-AS] provides the list=20= of use cases, and describes the common aspects of between=20 existing Energy standards and the EMAN standard, and shows how=20= the EMAN framework relates to other frameworks.=20 =20 =20 2. The Internet-Standard Management Framework=20 For a detailed overview of the documents that describe the=20 current Internet-Standard Management Framework, please refer to=20= section 7 of RFC 3410 [RFC3410].=20 =20 Managed objects are accessed via a virtual information store,=20 termed the Management Information Base or MIB. MIB objects are=20= generally accessed through the Simple Network Management=20 Protocol (SNMP). Objects in the MIB are defined using the=20 mechanisms defined in the Structure of Management Information=20 (SMI). This memo specifies MIB modules that are compliant with=20= SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58,=20= RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].=20 =20 =20 3. Requirements and Use Cases=20 Firstly, to illustrate the importance of energy monitoring in=20 networks and secondly to list some of the important areas to be=20= addressed by the Energy Management Framework, several use cases=20= and network scenarios are presented in the EMAN applicability=20 statement document [EMAN-AS]. In addition, for each scenario,=20 the target devices for energy management, and how those devices=20= powered and metered are also presented. To address the network=20= scenarios, requirements for power and energy monitoring for=20 networking devices are specified in [RFC6988]. Based on the=20 requirements [RFC6988], the [EMAN-FMWK] presents a solution=20 approach. =20 =20 Accordingly, the scope of the MIB modules in this document is in=20= accordance to the requirements specified in [RFC6988] and the=20 concepts from [EMAN-FMWK]. =20 =20 =20 4. Terminology=20 =20 =20 =20 Expires June 13, 2014 [Page 4]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Please refer to [EMAN-FMWK] for the definitions of the following=20= terminology used in this draft:=20 =20 Energy Management =20 =20 Energy Management System (EnMS) =20 TOM: This is not a great acronym as Element Management System (EMS) is = commonly used. =20 Energy Monitoring =20 =20 Energy Control =20 =20 electrical equipment =20 =20 non-electrical equipment (mechanical equipment) =20 =20 device =20 =20 component =20 =20 power inlet =20 =20 power outlet =20 =20 energy =20 =20 power =20 =20 demand =20 =20 provide energy =20 =20 receive energy =20 =20 meter (energy meter) =20 =20 battery =20 =20 Power Interface =20 =20 Nameplate Power =20 =20 Power Attributes =20 =20 Power Quality =20 =20 Power State =20 =20 Power State Set =20 =20 =20 Expires June 13, 2014 [Page 5]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 =20 5. Architecture Concepts Applied to the MIB Module=20 This section describes the basic concepts specified in the=20 Energy Management Architecture [EMAN-FMWK], with specific=20 information related to the MIB modules specified in this=20 document.=20 =20 The Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) MIB module=20= in this document specifies MIB objects for identification of=20 Energy Objects, and reporting context and relationship of an=20 Energy Object. The managed objects are contained in two tables=20= eoTable and eoRelationTable.=20 =20 The first table eoTable focuses on link to the other MIB=20 modules, context of the Energy Object. The second table=20 eoRelationTable specifies the relationships between Energy=20 Objects. This is a simplified representation of relationship=20 between Energy Objects. =20 =20 +- eoTable(2)=20 |=20 +- eoEntry(1) [entPhysicalIndex]=20 | | =20 | +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1)=20 | +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2)=20= | +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3)=20= | +-- rwn MacAddress eoMgmtMacAddress(4)=20= | +-- r-n InetAddressType eoMgmtAddressType(5)=20= | +-- r-n InetAddress eoMgmtAddress(6)=20 | +-- r-n SnmpAdminString eoMgmtDNSName(7)=20 | +-- rwn SnmpAdminString eoDomainName(8)=20 | +-- rwn SnmpAdminString eoRoleDescription(9)=20= | +-- rwn EnergyObjectKeywordList eoKeywords(10)=20 | +-- rwn Integer32 eoImportance(11)=20 | +-- r-n INTEGER eoPowerCategory(12)=20= | +-- rwn SnmpAdminString eoAlternateKey(13)=20 | +-- r-n INTEGER eoPowerInterfaceType(14)=20= TOM: I am having a hard time understanding what the XXX field before the = object types means here. I guess I understand the r =3D=3D read and w =3D=3D= write but what is "n"? I'd suggest just removing this column = altogether. Whether or not the objec tis read/write/whatever doesn't = seem important; what you want to get across here is the overall = structure/tree of things. | +- eoRelationTable(2)=20 | | =20 | +- eoRelationEntry(1) [entPhysicalIndex,=20 eoRelationIndex]=20 | | |=20 | | +-- --n Integer32 eoRelationIndex(1) =20= | | +-- --n UUIDorZero eoRelationID(2)=20 =20 =20 Expires June 13, 2014 [Page 6]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 | | +-- rwn IANAEnergyRelationship =20 eoRelationship(3)=20 =20 The following UML diagram illustrates the relationship of the=20 MIB objects in the eoTable, eoRelationTable that describe the=20 identity, context and relationship of an Energy Object. =20 =20 =20 +--------------------------+=20 | EO Context Information |=20 | ------------------------ | =20 | eoRoleDescription |=20 | eoKeywords | =20 | eoImportance |=20 | eoPowerCategory |=20 | eoPowerInterfaceType | =20 +--------------------------+ =20 | =20 | =20 v =20 +-----------------------------+ =20 |---> | EO Identification |=20 | |_---------------------------- |=20 TOM: Is the ^^^ a typo? | | entPhysicalIndex (*) |=20 | | entPhysicalName (*) |=20 | | entPhysicalUUID (*) |=20 | | |=20 | | eoEthPortIndex (**) |=20 | | eoEthPortGrpIndex (**) |=20 | | eoLldpPortNumber (***) |=20 | | eoAlternateKey |=20 | | |=20 | | eoMgmtMacAddress (optional) |=20 | | eoMgmtAddressType (optional) |=20 | | eoMgmtAddress (optional) |=20 | | eoMgmtDNSName (optional) |=20 | | eoDomainName |=20 | +------------------------------+ =20 | =20 | +------------------------------+=20 |---- | EO Relationship |=20 | | ---------------------------- | =20 | | eoRelationIndex |=20 | | eoRelationID | =20 | | IANAEnergyRelationship |=20 | +------------------------------+ =20 =20 =20 =20 =20 Expires June 13, 2014 [Page 7]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 =20 (*) Compliance with the ENTITY MIB V4 [RFC6933]=20 (**) Link with the Power over Ethernet MIB [RFC3621]=20 (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB]=20 =20 =20 Figure 1: MIB Objects Grouping=20 =20 =20 As displayed in figure 1, the MIB objects can be classified in=20= different logical grouping of MIB objects. =20 TOM: grouping -> groupings =20 1) The Energy Object Identification. See Section 5.1 "Energy=20 Object Identification". Devices and their sub-components are=20= characterized by the power-related attributes of a physical=20 entity present in the ENTITY MIB [RFC6933].=20 2) The Context Information. See Section 5.2 "Energy Object=20 Context"=20 3) The links to other MIB modules. See Section 5.3 "Links to=20 other Identifiers" =20 4) The Energy Object Relationships specific information. See=20 Section 5.4=20 5) The Energy Object Identity Persistence. See Section 5.5=20 "Energy Object Identity Persistence"=20 =20 =20 5.1 Energy Object Identification =20 Refer to the "Energy Object Information" section in [EMAN-FMWK]=20= for background information about Energy Objects. =20 =20 Every Energy Object MUST implement the unique index,=20 entPhysicalIndex, entPhysicalName and entPhysicalUUID from the=20= ENTITY MIB [RFC6933]. Module Compliance with respect to=20 entity4CRCompliance of ENTITY-MIB should be supported which=20 require a limited number of objects supported (entPhysicalClass,=20= entPhysicalName, entPhysicalUUID). entPhysicalIndex is used as=20= index for the primary Energy Object information in the ENERGY- OBJECT-CONTEXT-MIB module.=20 =20 Every Energy Object MUST have a printable name assigned to it.=20= TOM: Can you be more specific with "printable"? Do you mean ASCII = etc...?=20 Energy Objects MUST implement the entPhysicalName object=20 specified in the ENTITY-MIB [RFC6933], which must contain the=20 Energy Object name. =20 =20 =20 Expires June 13, 2014 [Page 8]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy=20 Object instance MUST implement the entPhysicalUUID from the=20 ENTITY MIB [RFC6933]. =20 As displayed in [RFC4122], the following is an example of the=20 string representation of a UUID as a URN: urn:uuid:f81d4fae- 7dec-11d0-a765-00a0c91e6bf6. =20 For example, to understand the relationship between Energy=20 Object Components and Energy Objects, the ENTITY-MIB physical=20 containment tree [RFC6933] MUST be implemented.=20 =20 A second example deals with one of the ENTITY-MIB extensions: if=20= the Energy Object temperature is required, the managed objects=20= from the ENTITY-SENSOR-MIB [RFC3433] should be supported.=20 =20 Each Energy Object MUST belong to a single Energy Management=20 Domain or in other words, an Energy Object cannot belong to more=20= than one Energy Management Domain. Refer to the "Energy=20 Management Domain" section in [EMAN-FMWK] for background=20 TOM: At present the EMAN-FMWK states that it SHOULD belong to a single = domain; this is inconsistent. information. The eoDomainName, which is an element of the=20 eoTable, is a read-write MIB object. The Energy Management=20 Domain should map 1-1 with a metered or sub-metered portion of=20= TOM: The framework uses "1:1"; perhaps you should use that too? the network. The Energy Management Domain MUST be configured on=20= the Energy Object. The Energy Object MAY inherit the some of the=20= domain parameters (possibly domain name, some of the context=20 information such as role or keywords, importance) from the=20 Energy Object or the Energy Management Domain MAY be configured=20= directly in an Energy Object. =20 =20 When an Energy Object acts as a Power Aggregator, the Energy=20 Objects for which Power should be aggregated MUST be members of=20= the same Energy Management Domain, specified by the eoDomainName=20= MIB Object. =20 TOM: Again, the MUST is inconsistent with the Framework at the present = time. =20 5.2 Energy Object Context=20 Refer to the "Energy Object Context" section in [EMAN-FMWK] for=20= background information.=20 =20 An Energy Object must provide a value for eoImportance in the=20 range of 1...100 to help differentiate the use or relative value=20= of the device. The importance range is from 1 (least important)=20= to 100 (most important). The default importance value is 1. =20 =20 =20 =20 Expires June 13, 2014 [Page 9]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 An Energy Object can provide a set of eoKeywords. These keywords=20= are a list of tags that can be used for grouping and summary=20 reporting within or between Energy Management Domains.=20 =20 An Energy Object can have Power Interfaces and those interfaces=20= can be classified as Power Inlet, Power Outlet or both. =20 =20 An Energy Object can be classified based on the physical=20 properties of the Energy Object. That Energy Object can be=20 classified as consuming power or supplying power to other=20 devices or that Energy Object can perform both of those=20 functions and finally, an Energy Object can be a passive meter. = =20 =20 Additionally, an Energy Object can provide an eoRoleDescription=20= string that indicates the purpose the Energy Object serves in=20 the network.=20 =20 =20 5.3 Links to Other Identifiers =20 While the entPhysicalIndex is the primary index for all MIB=20 objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy=20 Management Systems (EnMS) must be able to make the link with the=20= TOM: Do you really mean (all caps) MUST here? identifier(s) in other supported MIB modules.=20 =20 If the Energy Object is a Power over Ethernet (PoE) port, and if=20= the Power over Ethernet MIB [RFC3621] is supported by the Energy=20= Object SNMP agent, then the Energy Object eoethPortIndex and=20 eoethPortGrpIndex MUST contain the values of pethPsePortIndex=20 and pethPsePortGroupIndex [RFC3621]. =20 =20 The Energy Object eoLldpPortNumber MUST contain the=20 lldpLocPortNum from the LLDP MIB [LLDP-MIB], if the LLDP-MED =20 MIB is supported on the Energy Object SNMP agent.=20 =20 The intent behind the links to the other MIB module=20 identifier(s) is to correlate the instances in the different MIB=20= modules. This will allow the ENERGY-OBJECT-CONTEXT-MIB module to=20= reference other MIB modules in cases where the Power over=20 Ethernet and the LLDP MIB modules are supported by the SNMP=20 agent. Some use cases may not implement any of these two MIB=20 TOM: I think you mean something like, "...may not implement either of = these MIB ..." modules for the Energy Objects. However, in situation where any=20= of these two MIB modules are implemented, the EnMS must be able=20= to correlate the instances in the different MIB modules.=20 =20 The eoAlternateKey alternate key object specifies a manufacturer=20= defined string that can be used to identify the Energy Object. =20= Since an EnMS may need to correlate objects across management=20 =20 =20 Expires June 13, 2014 [Page 10]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 systems, this alternate key is provided to facilitate such a=20 link. This optional value is intended as a foreign key or=20 alternate identifier for a manufacturer or EnMS to use to=20 correlate the unique Energy Object Id in other systems or=20 namespaces. If an alternate key is not available or is not=20 applicable then the value is the zero-length string.=20 TOM: Do you want to use MUST here to indicate that it MUST be the = zero-length string?=20 =20 =20 5.4 Energy Object Relationships=20 Refer to the "Energy Object Relationships" section in [EMAN- FMWK] for the definition and background information.=20 In order to link two Energy Objects a separate table=20 (eoRelationTable) has been introduced in this MIB module. The=20 following relationships between Energy objects have been=20 considered in the eoRelationTable. =20 =20 =20 Metering Relationship -> meteredBy/metering=20 =20 =20 Power Source Relationship -> poweredBy/powering=20 =20 =20 Aggregation Relationship -> aggregatedBy/aggregating =20 =20 Each Energy object can have one or more Energy Object=20 relationships with other Energy Objects. The relations between=20= Energy Objects are specified in eoRelationTable. The=20 relationship between the Energy Objects is specified with an=20 arbitrary index and the UUID of the remote Energy Object. The=20 UUID MUST comply to the RFC 4122 specifications. It is=20 important to note that it is possible that an Energy Object may=20= TOM: may -> might not have an Energy Object relationship with other Energy=20 Objects. =20 =20 The IANA Energy Relationship MIB module specifies the first=20 version of the IANA-maintained definitions of relationships=20 between Energy Objects, as textual conventions. This way, for=20 Energy Relationships, new textual conventions can be specified,=20= without updating the primary Energy Object Context MIB module.=20= =20 Since the communication between the Energy Objects may not be=20 SNMP and is left to the choice of the device manufacturer, an=20 Energy Object can have additional MIB objects that can be used=20= for easier identification by the EnMS. The optional objects=20 eoMgmtMacAddress, eoMgmtAddressType eoMgmtDNSName can be used to=20= help identify the relationship between the Energy Objects and=20 other NMS objects. These objects can be used as an alternate=20 =20 =20 Expires June 13, 2014 [Page 11]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 key to help link the Energy Object with other keyed information=20= that may be stored within the EnMS(s). For the optional objects=20= that may not be included in some vendor implementations, the=20 expected behavior when those objects are polled is a response=20 noSuchInstance.=20 =20 =20 5.5 Energy Object Identity Persistence=20 In some situations, the Energy Object identity information=20 should be persistent even after a device reload. For example, in=20= a static setup where a switch monitors a series of connected PoE=20= phones, there is a clear benefit for the EnMS if the Energy=20 Object Identification and all associated information persist, as=20= it saves a network discovery. However, in other situations,=20 such as a wireless access point monitoring the mobile user PCs,=20= there is not much advantage to persist the Energy Object=20 Information. The identity information of an Energy Object=20 should be persisted and there is value in the writable MIB=20 objects persisted.=20 =20 =20 6. MIB Definitions=20 =20 -- ************************************************************=20= -- =20 -- =20 -- This MIB is used for describing the identity and the =20 -- context information of Energy Objects in network =20 TOM: "in network" -> "in a network" ? -- =20 -- =20 -- *************************************************************=20= =20 =20 ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::=3D BEGIN=20 =20 IMPORTS=20 MODULE-IDENTITY,=20 OBJECT-TYPE,=20 mib-2,=20 Integer32=20 FROM SNMPv2-SMI =20 TEXTUAL-CONVENTION, MacAddress, TruthValue=20 FROM SNMPv2-TC=20 MODULE-COMPLIANCE,=20 OBJECT-GROUP=20 =20 =20 Expires June 13, 2014 [Page 12]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 FROM SNMPv2-CONF=20 SnmpAdminString=20 FROM SNMP-FRAMEWORK-MIB =20 InetAddressType, InetAddress=20 FROM INET-ADDRESS-MIB =20 entPhysicalIndex=20 FROM ENTITY-MIB =20 TOM: I generally like to include a comment after each MIB stating which = RFC it comes from. It is a good habit since not all MIB modules are = easily found for compilation. UUIDorZero=20 FROM UUID-TC-MIB =20 TOM: You should include a reference to RFC6933 here IANAEnergyRelationship=20 FROM IANA-ENERGY-RELATION-MIB; =20 =20 energyObjectContextMIB MODULE-IDENTITY=20 LAST-UPDATED "201312130000Z"=20 =20 ORGANIZATION "IETF EMAN Working Group"=20 CONTACT-INFO=20 "WG Charter:=20 http://datatracker.ietf.org/wg/eman/charter/=20 =20 Mailing Lists:=20 General Discussion: eman@ietf.org=20 To Subscribe: https://www.ietf.org/mailman/listinfo/eman=20= Archive: http://www.ietf.org/mail-archive/web/eman=20 Editors: =20 John Parello =20 Cisco Systems, Inc. =20 3550 Cisco Way =20 San Jose, California 95134 =20 US =20 Phone: +1 408 525 2339 =20 Email: jparello@cisco.com =20 =20 =20 Benoit Claise=20 Cisco Systems, Inc.=20 De Kleetlaan 6a b1=20 Degem 1831=20 Belgium=20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 =20 =20 Mouli Chandramouli=20 =20 =20 Expires June 13, 2014 [Page 13]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Cisco Systems, Inc.=20 Sarjapur Outer Ring Road=20 Bangalore 560103=20 IN=20 Phone: +91 80 4429 2409=20 Email: moulchan@cisco.com"=20 =20 =20 DESCRIPTION=20 "This MIB is used for describing the identity and the =20 context information of Energy Objects"=20 REVISION=20 "201312130000Z"=20 DESCRIPTION=20 "Initial version, published as RFC YYY."=20 =20 =20 ::=3D { energyMIB 1 } =20 TOM: I believe that the WG (and MIB doctors) decided to root these MIBs = under transmission, as usual. Please replace this with a note to the RFC = editor and IANA asking for such an assignment. =20 energyObjectContextMIBNotifs OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIB 0 }=20 =20 energyObjectContextMIBObjects OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIB 1 }=20 =20 energyObjectContextMIBConform OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIB 2 }=20 =20 =20 -- Textual Conventions=20 TOM: The naming of all of these objects is unusual. The "PethPse" prefix = in particular. Typically MIB variables and tables are somehow related to = the module/table they are contained in. It would be burdensome to = rename every thing in the module at this point, so I would be happy if = you simply defined what these prefixes meant for the uninitiated reader. = =20 =20 PethPsePortIndexOrZero ::=3D TEXTUAL-CONVENTION=20 DISPLAY-HINT "d"=20 STATUS current=20 DESCRIPTION=20 "This textual convention is an extension of the=20 pethPsePortIndex convention, which defines a greater than=20= zero value used to identify a power Ethernet PSE port. =20= This extension permits the additional value of zero. The=20= semantics of the value zero are object-specific and must,=20= therefore, be defined as part of the description of any=20= object that uses this syntax. Examples of the usage of=20= this extension are situations where none or all physical=20= entities need to be referenced."=20 SYNTAX Integer32 (0..2147483647)=20 =20 =20 Expires June 13, 2014 [Page 14]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 PethPsePortGroupIndexOrZero ::=3D TEXTUAL-CONVENTION=20 DISPLAY-HINT "d"=20 STATUS current=20 DESCRIPTION=20 "This textual convention is an extension of the=20 pethPsePortGroupIndex convention from the Power Over=20 Ethernet MIB [RFC3621], which defines a greater than zero=20= value used to identify group containing the port to which=20= a power Ethernet PSE is connected. This extension=20 permits the additional value of zero. The semantics of=20= the value zero are object-specific and must, therefore,=20= be defined as part of the description of any object that=20= uses this syntax. Examples of the usage of this=20 extension are situations where none or all physical=20 entities need to be referenced."=20 SYNTAX Integer32 (0..2147483647)=20 =20 LldpPortNumberOrZero ::=3D TEXTUAL-CONVENTION =20 DISPLAY-HINT "d" =20 STATUS current =20 DESCRIPTION =20 "This textual convention is an extension of the=20 LldpPortNumber convention specified in the LLDP MIB,=20 which defines a greater than zero value used to uniquely=20= identify each port contained in the chassis (that is=20 known to the LLDP agent) by a port number. This=20 extension permits the additional value of zero. The=20 semantics of the value zero are object-specific and must,=20= therefore, be defined as part of the description of any=20= object that uses this syntax. Examples of the usage of=20= this extension are situations where none or all physical=20= entities need to be referenced."=20 SYNTAX Integer32(0..4096)=20 =20 EnergyObjectKeywordList ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 "A list of keywords that can be used to group Energy=20 Objects for reporting or searching. If multiple keywords=20= are present, then this string will contain all the=20 keywords separated by the ',' character. All alphanumeric=20= =20 =20 Expires June 13, 2014 [Page 15]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 characters and symbols (other than a comma), such as #,=20= (, $, !, and &, are allowed. White spaces before and=20 after the commas are ignored, as well as within a keyword=20= itself. =20 =20 For example, if an Energy Object were to be tagged with=20= the keyword values 'hospitality' and 'guest', then the=20 keyword list will be 'hospitality,guest'."=20 SYNTAX OCTET STRING (SIZE (0..2048))=20 =20 -- Objects=20 =20 eoTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table lists Energy Objects."=20 ::=3D { energyObjectContextMIBObjects 1 }=20 =20 eoEntry OBJECT-TYPE=20 SYNTAX EoEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry describes the attributes of an Energy Object. =20= Whenever a new Energy Object is added or an existing=20 Energy Object is deleted, a row in the eoTable is added=20= or deleted."=20 =20 INDEX {entPhysicalIndex }=20 ::=3D { eoTable 1 }=20 =20 EoEntry ::=3D SEQUENCE {=20 eoEthPortIndex PethPsePortIndexOrZero,=20 eoEthPortGrpIndex PethPsePortGroupIndexOrZero,=20= eoLldpPortNumber LldpPortNumberOrZero,=20 eoMgmtMacAddress MacAddress,=20 eoMgmtAddressType InetAddressType,=20 eoMgmtAddress InetAddress,=20 eoMgmtDNSName SnmpAdminString,=20 eoDomainName SnmpAdminString,=20 eoRoleDescription SnmpAdminString,=20 eoKeywords EnergyObjectKeywordList,=20 eoImportance Integer32,=20 eoPowerCategory INTEGER,=20 #TOM: You should not use INTEGER; use Integer32 instead. =20 Expires June 13, 2014 [Page 16]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 eoAlternateKey SnmpAdminString, =20 eoPowerInterfaceType INTEGER=20 #TOM: You should not use INTEGER; use Integer32 instead. } =20 =20 eoEthPortIndex OBJECT-TYPE =20 SYNTAX PethPsePortIndexOrZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION =20 "This variable uniquely identifies the power Ethernet=20 port to which the attached device is connected [RFC3621].=20= In addition, PoE MIB should be instantiated on the=20 device. If such a power Ethernet port cannot be specified=20= or is not known then the object is zero."=20 ::=3D { eoEntry 1 }=20 TOM: Should this have a DEFVAL of 0? =20 eoEthPortGrpIndex OBJECT-TYPE =20 SYNTAX PethPsePortGroupIndexOrZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This variable uniquely identifies the group containing=20= the port to which a power Ethernet PSE is connected=20 [RFC3621]. In addition, PoE MIB should be instantiated on=20= the device. If such a group cannot be specified or is not=20= known then the object is zero."=20 ::=3D { eoEntry 2 }=20 =20 eoLldpPortNumber OBJECT-TYPE =20 SYNTAX LldpPortNumberOrZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This variable uniquely identifies the port component=20 (contained in the local chassis with the LLDP agent) as=20 defined by the lldpLocPortNum in the [LLDP-MIB] and=20 [LLDP-MED-MIB]. In addition, LLDP MIB should be=20 TOM: These references should not be used inline. Remember that once the = MIB is stripped out of this draft, those references have no meaning. = Please either add a Reference clause below, or use an RFC/IEEE number = that can easily be found. Please go through every place where there is = a reference in a DESCRIPTION clause and make this correction as I will = not comment on each and every one. instantiated on the device If such a port number cannot=20 be specified or is not known then the object is zero."=20 ::=3D { eoEntry 3 }=20 =20 eoMgmtMacAddress OBJECT-TYPE=20 SYNTAX MacAddress =20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies a MAC address of the Energy=20 Object." =20 =20 =20 Expires June 13, 2014 [Page 17]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 ::=3D { eoEntry 4 }=20 =20 eoMgmtAddressType OBJECT-TYPE=20 SYNTAX InetAddressType=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the eoMgmtAddress type, i.e. an=20 IPv4 address or an IPv6 address. This object MUST be=20 populated when eoMgmtAddress is populated." =20 ::=3D { eoEntry 5 }=20 =20 eoMgmtAddress OBJECT-TYPE=20 SYNTAX InetAddress=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the management address as an IPv4=20= address or IPv6 address of Energy Object. The IP address=20= type, i.e. IPv4 or IPv6, is determined by the=20 eoMgmtAddressType value. This object can be used as an=20 alternate key to help link the Energy Object with other=20 keyed information that may be stored within the EnMS(s)." =20= ::=3D { eoEntry 6 }=20 =20 eoMgmtDNSName OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the DNS name of the eoMgmtAddress.=20= This object can be used as an alternate key to help link=20= the Energy Object with other keyed information that may=20= be stored within the EnMS(s)."=20 ::=3D { eoEntry 7 }=20 TOM: Is there anything you want to say about any (suggested) format for = this string? =20 eoDomainName OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object specifies the name of an Energy Management=20= Domain for the Energy Object. This object specifies a=20 zero-length string value if no Energy Management Domain=20= name is configured. The value of eoDomainName must remain=20= constant at least from one re-initialization of the=20 entity local management system to the next re- initialization." =20 =20 =20 Expires June 13, 2014 [Page 18]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 ::=3D { eoEntry 8 }=20 TOM: Should this be an empty string by default so that it is set into a = known state? =20 eoRoleDescription OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object specifies an administratively assigned name=20= to indicate the purpose an Energy Object serves in the=20 network.=20 =20 For example, we can have a phone deployed to a lobby with=20= eoRoleDescription as 'Lobby phone'.=20 =20 This object specifies the value is the zero-length string=20= TOM: specifies THAT the value... value if no role description is configured.=20 The value of eoRoleDescription must remain constant at=20 least from one re-initialization of the entity local =20 management system to the next re-initialization. " =20 ::=3D { eoEntry 9 } =20 =20 eoKeywords OBJECT-TYPE=20 SYNTAX EnergyObjectKeywordList=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object specifies a list of keywords that can be=20 used to group Energy Objects for reporting or searching. =20= The value is the zero-length string if no keywords have=20= been configured. If multiple keywords are present, then=20= this string will contain all the keywords separated by=20 the ',' character. For example, if an Energy Object were=20= to be tagged with the keyword values 'hospitality' and=20 'guest', then the keyword list will be=20 'hospitality,guest'. =20 =20 If write access is implemented and a value is written=20 into the instance, the agent must retain the supplied=20 value in the eoKeywords instance associated with=20 the same physical entity for as long as that entity=20 remains instantiated. This includes instantiations=20 across all re-initializations/reboots of the local=20 management agent. " =20 ::=3D { eoEntry 10 }=20 =20 eoImportance OBJECT-TYPE=20 SYNTAX Integer32 (1..100)=20 MAX-ACCESS read-write=20 =20 =20 Expires June 13, 2014 [Page 19]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 STATUS current=20 DESCRIPTION =20 "This object specifies a ranking of how important the=20 Energy Object is (on a scale of 1 to 100) compared with=20= other Energy Objects in the same Energy Management=20 Domain. The ranking should provide a business or=20 operational context for the Energy Object as compared to=20= other similar Energy Objects. This ranking could be used=20= as input for policy-based network management. =20 =20 =20 Although network managers must establish their own=20 ranking, the following is a broad recommendation:=20 =20 90 to 100 Emergency response =20 80 to 90 Executive or business critical =20 70 to 79 General or Average =20 60 to 69 Staff or support =20 40 to 59 Public or guest =20 1 to 39 Decorative or hospitality=20 =20 The value of eoImportance must remain constant at least=20= from one re-initialization of the entity local =20 management system to the next re-initialization. "=20 DEFVAL { 1 } =20 ::=3D { eoEntry 11 }=20 =20 eoPowerCategory OBJECT-TYPE=20 SYNTAX INTEGER {=20 #TOM: You should not use INTEGER; use Integer32 instead. consumer(0),=20 producer(1), =20 meter(2),=20 distributor(3),=20 store(4)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object describes the Energy Object category, which=20= indicates the expected behavior or physical property of=20= the Energy Object, based on its design. An Energy Object=20= can be a consumer(0), producer(1), meter(2),=20 distributor(3) or store(4). =20 =20 In some cases, a meter is required to measure the power=20= consumption. In such a case, this meter Energy Object=20 category is meter(2). If a device is functioning as a=20 distributor of Energy that category of the Energy Object=20= =20 =20 Expires June 13, 2014 [Page 20]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 is distributor (3). If a device is a store of electric=20 Energy the category of the device can be store (4). " =20 ::=3D { eoEntry 12 }=20 TOM: These definitions are a bit recursive. Is there perhaps a better = reference (i.e.: the framework or somethign) that better = defines/describes these? =20 eoAlternateKey OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-write =20 STATUS current=20 DESCRIPTION=20 "This object specifies a manufacturer defined string that=20= can be used to identify the Energy Object. Since Energy=20= Management Systems (EnMS) and Network Management Systems=20= (NMS) may need to correlate objects across management=20 systems, this alternate key is provided to provide such a=20= link. This optional value is intended as a foreign key or=20= alternate identifier for a manufacturer or EnMS/NMS to=20 use to correlate the unique Energy Object Id in other=20 systems or namespaces. If an alternate key is not=20 available or is not applicable then the value is the=20 zero-length string. =20 The value of eoAlternateKey must remain constant at =20 least from one re-initialization of the entity local =20 management system to the next re-initialization. " =20 ::=3D { eoEntry 13 }=20 =20 eoPowerInterfaceType OBJECT-TYPE=20 SYNTAX INTEGER {=20 #TOM: You should not use INTEGER; use Integer32 instead. inlet(0),=20 outlet(1), =20 both(2) =20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object describes the Power Interface for an Energy=20= Object. A Power Interface is an interface at which a=20 Energy Object is connected to a power transmission=20 medium, at which it can in turn receive power, provide=20 power, or both. A Power Interface type can be an inlet(0)=20= or outlet(1) or both(2), respectively." =20 TOM: Not sure "respectively" adds anything to the last sentence. Also, = are these states defined in the framework and if so, should there be a = reference? ::=3D { eoEntry 14 }=20 =20 eoRelationTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoRelationEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 =20 =20 Expires June 13, 2014 [Page 21]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 "This table describes the relationships between Energy=20 Objects."=20 TOM: This is a rather terse definition of the table. Can you add = anything else here? ::=3D { energyObjectContextMIBObjects 2 }=20 =20 =20 eoRelationEntry OBJECT-TYPE=20 SYNTAX EoRelationEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry in this table describes the relationship=20 between Energy objects."=20 INDEX { entPhysicalIndex, eoRelationIndex }=20 ::=3D { eoRelationTable 1 }=20 =20 =20 EoRelationEntry ::=3D SEQUENCE {=20 eoRelationIndex Integer32,=20 eoRelationID UUIDorZero,=20 eoRelationship IANAEnergyRelationship = =20 }=20 =20 eoRelationIndex OBJECT-TYPE=20 SYNTAX Integer32 (0..2147483647) =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This object is an arbitrary index to identify the Energy=20= Object related to another Energy Object" =20 ::=3D { eoRelationEntry 1 }=20 =20 eoRelationID OBJECT-TYPE=20 SYNTAX UUIDorZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the Universally Unique Identifier=20= (UUID) of the peer (other) Energy Object. The UUID must=20 comply the specifications of UUID in UUID-TC-MIB. =20 =20 If UUID of the energy object is unknown or non-existent, =20= the eoRelationID will be set to a zero-length string =20 instead."=20 =20 REFERENCE=20 "RFC 6933, Entity MIB - version 4, May 2013 "=20 ::=3D { eoRelationEntry 2 }=20 =20 =20 Expires June 13, 2014 [Page 22]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 eoRelationship OBJECT-TYPE=20 SYNTAX IANAEnergyRelationship=20 MAX-ACCESS read-write =20 STATUS current=20 DESCRIPTION=20 "This object describes the relations between Energy=20 objects. For each Energy object, the relations between=20 the other Energy objects are specified using the bitmap." =20= ::=3D { eoRelationEntry 3 }=20 =20 -- Conformance=20 =20 energyObjectContextMIBCompliances OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIBConform 1 }=20 =20 energyObjectContextMIBGroups OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIBConform 2 }=20 =20 energyObjectContextMIBFullCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "When this MIB is implemented with support for=20 read-write, then such an implementation can =20 claim full compliance. Such devices can then =20 be both monitored and configured with this MIB."=20 MODULE -- this module=20 MANDATORY-GROUPS {=20 energyObjectContextMIBTableGroup, =20 energyObjectRelationTableGroup =20 }=20 =20 GROUP energyObjectOptionalMIBTableGroup=20 DESCRIPTION=20 "A compliant implementation does not have to =20 implement. Module Compliance of ENTITY-MIB =20 with respect to entity4CRCompliance should =20 be supported. "=20 ::=3D { energyObjectContextMIBCompliances 1 }=20 =20 =20 energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "When this MIB is implemented without support for=20 read-write (i.e. in read-only mode), then such an =20 implementation can claim read-only compliance. =20 =20 =20 Expires June 13, 2014 [Page 23]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Such a device can then be monitored but cannot be =20 Configured with this MIB. =20 Module Compliance of ENTITY-MIB with respect to =20 entity4CRCompliance should be supported."=20 MODULE -- this module=20 =20 MANDATORY-GROUPS {=20 energyObjectContextMIBTableGroup, =20 energyObjectRelationTableGroup=20 }=20 =20 GROUP energyObjectOptionalMIBTableGroup=20 DESCRIPTION=20 "A compliant implementation does not have to implement =20 the managed objects in this GROUP. =20 Module Compliance of ENTITY-MIB =20 with respect to entity4CRCompliance should =20 be supported. "=20 ::=3D { energyObjectContextMIBCompliances 2 }=20 =20 -- Units of Conformance=20 =20 energyObjectContextMIBTableGroup OBJECT-GROUP=20 OBJECTS { =20 eoDomainName,=20 eoRoleDescription,=20 eoAlternateKey,=20 eoKeywords,=20 eoImportance,=20 eoPowerCategory,=20 eoPowerInterfaceType =20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the objects=20= related to the EnergyObject. =20 Module Compliance of ENTITY-MIB =20 with respect to entity4CRCompliance should =20 be supported. "=20 ::=3D { energyObjectContextMIBGroups 1 }=20 =20 energyObjectOptionalMIBTableGroup OBJECT-GROUP=20 OBJECTS { =20 eoEthPortIndex,=20 eoEthPortGrpIndex,=20 eoLldpPortNumber,=20 eoMgmtMacAddress,=20 eoMgmtAddressType,=20 =20 =20 Expires June 13, 2014 [Page 24]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 eoMgmtAddress,=20 eoMgmtDNSName =20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the objects=20= related to the Energy Object."=20 ::=3D { energyObjectContextMIBGroups 2 }=20 =20 energyObjectRelationTableGroup OBJECT-GROUP=20 OBJECTS { =20 -- Note that object eoRelationIndex is not=20= -- included since it is not-accessible=20 =20 eoRelationID, =20 eoRelationship=20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all objects=20 specifying the relationship between Energy Objects."=20 ::=3D { energyObjectContextMIBGroups 3 }=20 =20 END=20 =20 =20 IANA-ENERGY-RELATION-MIB DEFINITIONS ::=3D BEGIN=20 IMPORTS=20 MODULE-IDENTITY, mib-2=20 FROM SNMPv2-SMI=20 TEXTUAL-CONVENTION=20 FROM SNMPv2-TC;=20 =20 ianaEnergyRelationMIB MODULE-IDENTITY=20 LAST-UPDATED "201312130000Z" -- December 13, 2013=20 ORGANIZATION "IANA"=20 CONTACT-INFO " =20 Internet Assigned Numbers Authority=20 Postal: ICANN=20 4676 Admiralty Way, Suite 330=20 Marina del Rey, CA 90292=20 Tel: +1-310-823-9358=20 EMail: iana&iana.org"=20 =20 =20 DESCRIPTION=20 "This MIB module defines a TEXTUAL-CONVENTION that=20 describes the relationships between Energy Objects.=20 =20 =20 Expires June 13, 2014 [Page 25]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 Copyright (C) The IETF Trust (2013).=20 =20 The initial version of this MIB module was published in=20= RFC YYY; for full legal notices see the RFC itself.=20 Supplementary information may be available at=20 http://www.ietf.org/copyrights/ianamib.html"=20 =20 =20 REVISION "201312130000Z" -- December 13, 2013=20 DESCRIPTION "Initial version of this MIB as published in=20= RFC YYY." =20 ::=3D { energyMIB 2 }=20 TOM: Re-root this OID and insert a note to IANA/RFC Editor here. = Generally for experimental MIBs you put in a dummy number here like = transmission XXX so it won't compile. =20 -- RFC Editor, please replace YYY with the IANA allocation=20= -- for this MIB module and YYY with the number of the =20 -- approved RFC=20 =20 -- Textual Conventions =20 =20 IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 "An enumerated value specifies the type of =20 relationship between Energy Objects.=20 =20 The enumeration 'poweredBy' is applicable if the =20 Energy Object A is poweredBy Energy Object B.=20 =20 The enumeration 'powering' is applicable if the =20 Energy Object A is powering Energy Object B.=20 =20 The enumeration 'meteredBy' is applicable if the =20 Energy Object A is meteredBy Energy Object B.=20 =20 The enumeration 'metering' is applicable if the =20 Energy Object A is metering Energy Object B.=20 =20 =20 The enumeration 'aggregatedBy' is applicable if the =20= Energy Object A is aggregatedBy Energy Object B.=20 =20 The enumeration 'aggregating' is applicable if the =20= Energy Object A is aggregating Energy Object B."=20 =20 SYNTAX INTEGER {=20 #TOM: You should not use INTEGER; use Integer32 instead. poweredBy(1), -- power relationship =20 powering(2),=20 =20 =20 Expires June 13, 2014 [Page 26]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 meteredBy(3), -- meter relationship =20 metering(4), =20 aggregatedBy(5), -- aggregation relationship =20= aggregating(6) =20 }=20 TOM: Should there be a reference here to where these values are actually = defined? =20 END=20 =20 =20 7. Implementation Status=20 [Note to RFC Editor: Please remove this section and the=20 reference to [RFC6982] before publication.]=20 =20 This section records the status of known implementations of the=20= EMAN-Monitoring MIB at the time of posting of this Internet- Draft, and is based on a proposal described in [RFC6982].=20 =20 The description of implementations in this section is intended=20 to assist the IETF in its decision processes in progressing=20 drafts to RFCs. =20 =20 11.1 SNMP Research =20 =20 Organization: SNMP Research, Inc.=20 =20 Maturity: Prototype based upon early drafts of the MIBs. =20 We anticipate updating it to more recent =20 documents as development schedules allow.=20 =20 Coverage: Code was generated to implement all MIB objects =20 in ENTITY-MIB (Version 4), =20 ENERGY-OBJECT-CONTEXT-MIB,=20 ENERGY-OBJECT-MIB, =20 POWER-CHARACTERISTICS-MIB,=20 and BATTERY-MIB.=20 =20 Implementation experience: The documents are implementable.=20 =20 Comments: Technical comments about the =20 ENERGY-OBJECT-CONTEXT-MIB,=20 ENERGY-OBJECT-MIB, and =20 BATTERY-MIB =20 were submitted to the EMAN Working Group =20 E-mail list. =20 =20 Licensing: Proprietary, royalty licensing=20 =20 =20 =20 Expires June 13, 2014 [Page 27]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Contact: Alan Luchuk, luchuk at snmp.com=20 =20 URL: http://www.snmp.com/=20 =20 =20 11.2 Python=20 =20 Priyanka Rao mentioned on the mailing list=20 (http://www.ietf.org/mail-archive/web/eman/current/msg02063.html)=20= That she has got an python implementation.=20 =20 =20 =20 8. Security Considerations =20 Some of the readable objects in these MIB modules (i.e., objects=20= with a MAX-ACCESS other than not-accessible) may be considered=20= sensitive or vulnerable in some network environments. It is=20 thus important to control even GET and/or NOTIFY access to these=20= objects and possibly to even encrypt the values of these objects=20= when sending them over the network via SNMP. =20 =20 There are a number of management objects defined in these MIB=20 modules with a MAX-ACCESS clause of read-write and/or read- create. Such objects MAY be considered sensitive or vulnerable=20= in some network environments. The support for SET operations in=20= a non-secure environment without proper protection can have a=20 negative effect on network operations. The following are the=20 tables and objects and their sensitivity/vulnerability:=20 =20 . Unauthorized changes to the eoDomainName, entPhysicalName,=20= eoRoleDescription, eoKeywords, and/or eoImportance MAY=20 disrupt power and energy collection, and therefore any=20 predefined policies defined in the network.=20 =20 =20 SNMP versions prior to SNMPv3 did not include adequate security.=20= Even if the network itself is secure (for example, by using=20 IPsec), there is still no secure control over who on the secure=20= network is allowed to access and GET/SET=20 (read/change/create/delete) the objects in these MIB modules.=20 =20 =20 It is RECOMMENDED that implementers consider the security=20 features as provided by the SNMPv3 framework (see [RFC3410],=20 section 8), including full support for the SNMPv3 cryptographic=20= mechanisms (for authentication and privacy).=20 =20 =20 Expires June 13, 2014 [Page 28]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 Further, deployment of SNMP versions prior to SNMPv3 is NOT=20 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=20= enable cryptographic security. It is then a customer/operator=20= responsibility to ensure that the SNMP entity giving access to=20= an instance of these MIB modules is properly configured to give=20= access to the objects only to those principals (users) that have=20= legitimate rights to GET or SET (change/create/delete) them.=20 =20 =20 9. IANA Considerations=20 TOM: The WG agreed to not root these modules under energyMIB, and = instead root each one under transmission on their own. Please correct = this. The MIB modules in this document uses the following IANA- TOM: uses -> use assigned OBJECT IDENTIFIER values recorded in the SMI Number=20 registry. =20 Descriptor OBJECT IDENTIFIER value=20 ---------- -----------------------=20 energyMIB { mib-2 XXX }=20 Editor's Note (to be removed prior to publication): IANA is=20 requested to assign a value for "XXX" under the 'mib-2' subtree=20= and to record the assignment in the SMI Numbers registry. When=20= the assignment has been made, the RFC Editor is asked to replace=20= "XXX" (here and in the MIB module) with the assigned value and=20= to remove this note.=20 This document defines the first version of the IANA-maintained=20= IANA-ENERGY-RELATION-MIB module, maintained by IANA, which allow=20= new definitions of relationships between Energy Objects. A=20 Specification Required as defined in RFC 5226 [RFC5226], is=20 REQUIRED for each modification or addition of the energy=20 relationships.=20 =20 10. Acknowledgement =20 We would like to thank Juergen Quittek and Juergen Schoenwalder=20= for their suggestions on the new design of eoRelationTable which=20= was a proposed solution for the open issue on the representation=20= of Energy Object as a UUIDlist. =20 =20 Many thanks to Juergen Quittek for many comments on the wording,=20= text and design of the MIB thus resulting in an improved draft. =20= =20 =20 =20 Expires June 13, 2014 [Page 29]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Many thanks to Alan Luchuk for the review of the MIB and his=20 comments.=20 =20 In addition the authors thank Bill Mielke for his multiple=20 reviews, Brad Schoening and Juergen Schoenwaelder for their=20 suggestions and Michael Brown for dramatically improving this=20 draft.=20 =20 And finally thanks the EMAN WG chairs: Nevil Brownlee and Tom=20 Nadeau. =20 =20 11. References=20 11.1. Normative References=20 =20 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate=20 Requirement Levels, BCP 14, RFC 2119, March 1997.=20 =20 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=20 Schoenwaelder, Ed., "Structure of Management=20 Information Version 2 (SMIv2)", STD 58, RFC 2578, April=20= 1999.=20 =20 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=20 Schoenwaelder, Ed., "Textual Conventions for SMIv2",=20 STD 58, RFC 2579, April 1999.=20 =20 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=20 "Conformance Statements for SMIv2", STD 58, RFC 2580,=20 April 1999.=20 =20 [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",=20 RFC3621, December 2003.=20 =20 =20 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally=20= Unique IDentifier (UUID) URN Namespace ", RFC 4122,=20 July 2005.=20 =20 [RFC6933] Bierman, A. Romascanu,D. Quittek, J. and M.=20 Chandramouli, "Entity MIB (Version 4)", RFC 6933, May=20 2013.=20 =20 [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base=20 module for LLDP configuration, statistics, local system=20= data and remote systems data components", May 2005.=20 =20 =20 =20 Expires June 13, 2014 [Page 30]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information=20= Base extension module for TIA-TR41.4 media endpoint=20 discovery information", July 2005.=20 =20 [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J.,=20 Dietz, T., and B. Claise "Power and Energy Monitoring=20= MIB", draft-ietf-eman-energy-monitoring-mib-07, October=20= 2013.=20 =20 =20 11.2. Informative References=20 =20 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,=20 "Introduction and Applicability Statements for Internet=20= Standard Management Framework", RFC 3410, December=20 2002.=20 =20 [RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity=20= Sensor Management Information Base", RFC 3433, December=20= 2002.=20 =20 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie,=20 "Guidelines for Writing an IANA Considerations Section=20= in RFCs ", BCP 26, RFC 5226, May 2008.=20 =20 [RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M.=20= Chandramouli, "Requirements for Energy Management", RFC=20= 6988, September 2013.=20 =20 [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J.=20 Quittek, "Energy Management Framework", draft-ietf- eman-framework-11, work in progress, November 2013.=20 =20 [EMAN-AS] Schoening, B., Chandramouli, M, and B. Nordman,=20 "Energy Management (EMAN) Applicability Statement",=20 draft-ietf-eman-applicability-statement-04.txt, work in=20= progress, October 2013.=20 =20 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of=20 Running Code: The Implementation Status Section", RFC=20 6982, July 2013.=20 =20 Authors' Addresses=20 =20 Benoit Claise=20 Cisco Systems, Inc.=20 De Kleetlaan 6a b1=20 =20 =20 Expires June 13, 2014 [Page 31]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Diegem 1813=20 BE=20 =20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 =20 =20 John Parello=20 Cisco Systems, Inc.=20 3550 Cisco Way =20 San Jose, California 95134 =20 US=20 =20 Phone: +1 408 525 2339=20 Email: jparello@cisco.com=20 =20 =20 Mouli Chandramouli=20 Cisco Systems, Inc.=20 Sarjapur Outer Ring Road=20 Bangalore 560103 =20 IN=20 =20 Phone: +91 80 4429 2409 =20 Email: moulchan@cisco.com=20 =20 =20 =20 Expires June 13, 2014 [Page 32]=20= =20 --Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3t4WAAoJEPcO+I7eiUJZAMQQAKWbnfsrBRTs24MUwGVbja9M 2djLOKvdANB7+dWB9yQGQb2+3S4XcS1sOXKmN5YMhl3IgkEwuAHTjSYRjgPgJ3XV i1DmfvlFeytYVWVuURw12MdXKP1hrXyHKml5pQvCgeiMhP/ey9dEjnqaRgNFcPPr j8NrTDVmwLulATVt8McbP8l/AwKTe8Vd1fPf2GlkYaFhZg45gid89vB+Ciylizts Q/8wmBIHsMD93HQjABS/xC3vcM8LBmABIDeGVR8CtoMfXw0HvinjpDluhTIHqWxx CgskoRrRpIIxlnvTX+A4OL4m0p5qfrsqmdzY7El+xEjB8pW4wn3jOMjqlaWpTV8R YA1uQW1pHtqD1jwiG2cyR3Rhr40nKh7Cqv1wbzZ22RRwcqq5wtKBnOn1yUVOQySe lM1rzDy9rsjinJ28jmkFxLtA+lLs7qMT3kn+Oued482Trmgsa1CR8WiAzbxtNK/x ZNi/0b+rnQKxJYutCYfr106YB/py/biKcUKp9BYkR4UAphC6CxiRXy60VGNcKQ2Z VK7FKUa36mZ1m5VvLY3wlYJmcyjfIVnKvqR+VskpayviWg5AO85YhBaL6oBdYHDB fl3r4or6XBnFwhhbE5x/+aZNt7hgxFgf4AQ/efz6VxXIxhsUJe/y0MeJXtVaQNN5 0I452CNQL+W4Tr44/LYd =PqwB -----END PGP SIGNATURE----- --Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3-- From tnadeau@lucidvision.com Tue Jan 21 13:29:07 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A1C1A0381; Tue, 21 Jan 2014 13:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 33vTEdiPvBcz; Tue, 21 Jan 2014 13:29:04 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8831A038E; Tue, 21 Jan 2014 13:29:03 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id AF9DB26C177C; Tue, 21 Jan 2014 16:29:02 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com> Date: Tue, 21 Jan 2014 16:29:02 -0500 Message-Id: <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com> To: "John Parello (jparello)" X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [MIB-DOCTORS] [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:29:07 -0000 --Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That is cool,but please put in a reference and (brief) = explanation into the text somewhere. To the casual or new reader, it is = not obvious. *) --Tom > Hi Tom >=20 > Thanks. Still going through the comments. For the first one regarding = EnMS acronym. That's was discussed at length and we adopted it since = ISO50001 used that to describe a management system for energy (as = opposed to NMS) >=20 > Not great but what's in use. >=20 > Jp >=20 > Sent from my iPad=20 > (expect ridiculous spelling mistakes)=20 >=20 > On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" = wrote: >=20 >>=20 >=20 --Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3uaeAAoJEPcO+I7eiUJZEiUP/jMRSKjymoXFfg6GmBcHc+uw yCkLAmAuy9KDYY0KK3Q1IvA//hVntU5QH6RDzWhHJsLOg5iuZpKyANFkCtI2pFyP ttnMQH1xwAt9iRdi6eWUagR+xUuT1daTYFA/94ExOnYTzgt7SLZHHaky07vDUaN1 RBiAZbom4ik8FmPxGOUCo5o6dmog7f7irBheYR/INzbl9uPsCpVfn64iV+saUPBq Z+bf/ictZRnEdJkHmHoN4MxCDgpCDUbP360Scf6M2i6Wi0raCbARViOd5bgSE34h hmpN0Idta9he4PB6uoP1SZmOtetIEg1t2/sBwclwsGA4yBf81RGBs47Put22K3Zd ERpGhj9IriGfz/4UlhhtEC/kMAzG2dH5xrE+aQaDT0WAkyKnRRg9gkAaKBX3BhrM ZMdrCWNirFRGGpQXfG2pbpk+cL89u41L3l9YpEa9I9u6HOJffzCQRIIzrDRcetlx mPkVQDMP2Z4QAXF3gCV+6cbkYqO9a+HcdqDifmNFNUvfxRwJ3qo5LIRoNvUKNt2u PK1T3U9ssd+F06zbQEtP8slP07HQJolR8HVmtS46hTaP+NPOvSPqo4GAiNunDE0E KbGg3kiarqLdhDJ5c43u/ExygaRB5o4358dHlRUVMrD2TdBLyXO13ltmwSTUpJ5i 3AlPM54SSOJyZ4qF5lly =bqSx -----END PGP SIGNATURE----- --Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10-- From jparello@cisco.com Tue Jan 21 13:25:43 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652541A0263; Tue, 21 Jan 2014 13:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 PLuLnmkF2s4r; Tue, 21 Jan 2014 13:25:40 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id ABF061A0356; Tue, 21 Jan 2014 13:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=434; q=dns/txt; s=iport; t=1390339540; x=1391549140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YmDH/GtRPLjrDw4u7MXS+sOfjaJZzXzLconFQklFhTg=; b=CsRWP++1XXa0enzXLzRA2+puYVRv6zuuiXsz7jXsu5qPY1mmf84OErwu Ncnly4HT8ERxzgn+Xv8vUY4htHMKvxp1ndYAZqp00Cbv/46YTBvq4GV3n wJyjUOhaiGYGnP/4HOFaFqhWrZwmnshYigZXqyqFk/SWlVVZO7zwTcww/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMLAHrl3lKtJV2d/2dsb2JhbABagwu1YYcfgRYWdIImAQEEOj8QAgEIDigQMiUCBA4FiAXDCxeOTDMHgySBFASYIpIYgy0 X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208";a="14478614" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 21 Jan 2014 21:25:40 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0LLPek5003494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 21:25:40 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.10]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 15:25:40 -0600 From: "John Parello (jparello)" To: Thomas Nadeau Thread-Topic: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPFurCuxcWU93Os0WLCEyAtjrnYpqPsNOX Date: Tue, 21 Jan 2014 21:25:39 +0000 Message-ID: <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com> References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> In-Reply-To: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 21 Jan 2014 15:02:34 -0800 Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [MIB-DOCTORS] [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:25:43 -0000 Hi Tom Thanks. Still going through the comments. For the first one regarding EnMS = acronym. That's was discussed at length and we adopted it since ISO50001 us= ed that to describe a management system for energy (as opposed to NMS) Not great but what's in use. Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" wrot= e: >=20 From bertietf@bwijnen.net Wed Jan 22 00:30:03 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3B1A037A; Wed, 22 Jan 2014 00:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TW36SXbqD2yJ; Wed, 22 Jan 2014 00:30:01 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9A1A02A4; Wed, 22 Jan 2014 00:30:00 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5tCA-0000Zm-9b; Wed, 22 Jan 2014 09:29:59 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W5tCA-0007VH-6w; Wed, 22 Jan 2014 09:29:58 +0100 Message-ID: <52DF8186.3020705@bwijnen.net> Date: Wed, 22 Jan 2014 09:29:58 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , "MIB Doctors (E-mail)" , eman mailing list References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> In-Reply-To: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e17f817ccb232e04e9c4c2328ec5f9a3 Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 08:30:03 -0000 On 21/01/14 21:52, Thomas Nadeau wrote: > 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules under transmission, rather than under the single OID energyMIB. These modules still use the older approach, so please correct them. EMAN MIB Modules under "transmission" ???? That sounds weird to me. I would think under mib-2 Bert From bclaise@cisco.com Wed Jan 22 02:27:19 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA31A041B for ; Wed, 22 Jan 2014 02:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Bq2RVcgw928h for ; Wed, 22 Jan 2014 02:27:17 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDF91A01EB for ; Wed, 22 Jan 2014 02:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9444; q=dns/txt; s=iport; t=1390386436; x=1391596036; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Lg59XpeDqoVuygFpjEai3a/jpS0+AzefmPES76sgQMY=; b=lvkdZ3myF4N2muGAA2yWg/sx91ZiqbmvTsdJfWnpaLhdhaX1O1zWjcpt MFop46kDmzgc8LC3kKx6H6gzqQeNgqgWtb8wG0XNKfqBVNcpCxCkE5+Ux PX1xtmRKkasnD7Jw8q6tj6gTv0f+jE0NDynNXU+hIsFQKxFRhzUa/6Bqd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcPAHWc31KQ/khN/2dsb2JhbABbgws4iTGrYYcfgREWdIIlAQEBBAEBAWsKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGAQwBBQIBAQWHfA3BSheOGhEBUAcGhDIEmCKGR4tRgy47gTU X-IronPort-AV: E=Sophos;i="4.95,698,1384300800"; d="scan'208,217";a="3333344" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2014 10:27:15 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0MAREOi009434; Wed, 22 Jan 2014 10:27:15 GMT Message-ID: <52DF9D02.6070306@cisco.com> Date: Wed, 22 Jan 2014 11:27:14 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Bert Wijnen (IETF)'" , "'Thomas Nadeau'" , "'Romascanu, Dan (Dan)'" References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> In-Reply-To: <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------040904080302070104020806" Cc: "'MIB Doctors \(E-mail\)'" Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:27:19 -0000 This is a multi-part message in MIME format. --------------040904080302070104020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adrian, All, As expected and desired, this generated some good discussions (also in a different email thread between the MIB doctors) So we went - from "SNMPSet is dead", as a comment to make people react - to "SNMPSet is dead?" - to "we do not require writable MIB modules" - A statement such as "The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs by working groups except in cases of clear utility and overwhelming consensus to do so. In all other cases, we recommend the use of tools such as Netconf/Netmod for configuration." - to "do not use writeable objects _for configuration_ in MIB modules" We could go with an IESG statement, but I propose to make it easy to start with, with a statement on the MIB doctors page (http://www.ietf.org/iesg/directorate/mib-doctors.html) "The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs for configuration purposes by working groups except in cases of clear utility and overwhelming consensus to do so. In all other cases, we recommend the use of NETCONF/YANG IETF standards for configuration, specifically in new charters." - I added "for configuration". SNMPSet could potentially be used for action. - I removed "such as" in "tools such as Netconf/Netmod for configuration." Not sure what you're referring to here Tom - I added "specifically in new charters." Right now, there are read-write MIB modules in EMAN. It would not be a sound idea to say now, specifically when documents went through LC: stop what you're doing, recharter to do YANG modules. What's key in EMAN is that an Information Model has been specified part of the framework. Feedback? Regards, Benoit > (speaking as not a MIB Doctor) > > I like that very much, thanks for the words Tom. > > Benoit, do you think this is a big enough issue that we should make it an IESG > statement? > Or do you just want to run it through the OPSAWG in some way? > > A > >> -----Original Message----- >> From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] >> Sent: 21 January 2014 15:30 >> To: Thomas Nadeau; Romascanu, Dan (Dan) >> Cc: MIB Doctors (E-mail); Farrel Adrian >> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? >> >> sounds good to me >> >> Bert >> >> On 21/01/14 16:14, Thomas Nadeau wrote: >>> Agreed. Something like, "The OPS Area henceforth strongly discourages >> the pursuit of writable SNMP MIBs by working groups except in cases of clear >> utility and overwhelming consensus to do so. In all other cases, we recommend >> the use of tools such as Netconf/Netmod for configuration." >>> --Tom >>> >>> >>>> Hi Tom, >>>> >>>> This is exactly my point. I think that we should not only say 'do not do > Sets >> using SNMP'. We should also say what to do instead. >>>> Regards, >>>> >>>> Dan >>>> >>>> >>>>> -----Original Message----- >>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>> .... >>>> >>>>> I do agree that guidance needs to be issues to developers and >>>>> especially IETF WGs on this matter. >>>>> >>>>> --Tom >>>>> >>>> >>> >>> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > . > --------------040904080302070104020806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Adrian, All,

As expected and desired, this generated some good discussions (also in a different email thread between the MIB doctors)

So we went
- from "SNMPSet is dead", as a comment to make people react
- to "SNMPSet is dead?"
- to "we do not require writable MIB modules"
- A statement such as "The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs by working groups except in cases of clear utility and overwhelming consensus to do so. In all other cases, we recommend the use of tools such as Netconf/Netmod for configuration."
- to "do not use writeable objects for configuration in MIB modules"

We could go with an IESG statement, but I propose to make it easy to start with, with a statement on the MIB doctors page (http://www.ietf.org/iesg/directorate/mib-doctors.html)
"The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs for configuration purposes by working groups except in cases of clear utility and overwhelming consensus to do so. In all other cases, we recommend the use of NETCONF/YANG IETF standards for configuration, specifically in new charters."
- I added "for configuration". SNMPSet could potentially be used for action.
- I removed "such as" in "tools such as Netconf/Netmod for configuration." Not sure what you're referring to here Tom
- I added "specifically in new charters." Right now, there are read-write MIB modules in EMAN. It would not be a sound idea to say now, specifically when documents went through LC: stop what you're doing, recharter to do YANG modules. What's key in EMAN is that an Information Model has been specified part of the framework.

Feedback?

Regards, Benoit

(speaking as not a MIB Doctor)

I like that very much, thanks for the words Tom.

Benoit, do you think this is a big enough issue that we should make it an IESG
statement?
Or do you just want to run it through the OPSAWG in some way?

A


-----Original Message-----
From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
Sent: 21 January 2014 15:30
To: Thomas Nadeau; Romascanu, Dan (Dan)
Cc: MIB Doctors (E-mail); Farrel Adrian
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

sounds good to me

Bert

On 21/01/14 16:14, Thomas Nadeau wrote:

	Agreed. Something like, "The OPS Area henceforth strongly discourages

the pursuit of writable SNMP MIBs by working groups except in cases of clear
utility and overwhelming consensus to do so. In all other cases, we recommend
the use of tools such as Netconf/Netmod for configuration."

	--Tom



Hi Tom,

This is exactly my point. I think that we should not only say 'do not do

Sets

using SNMP'. We should also say what to do instead.

Regards,

Dan



-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]

....


	I do agree that guidance needs to be issues to developers and
especially IETF WGs on this matter.

	--Tom






_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors
.

--------------040904080302070104020806-- From bclaise@cisco.com Wed Jan 22 02:28:46 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633331A01EB; Wed, 22 Jan 2014 02:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Ov3xDaFfxAyz; Wed, 22 Jan 2014 02:28:45 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B025B1A041E; Wed, 22 Jan 2014 02:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=688; q=dns/txt; s=iport; t=1390386524; x=1391596124; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Pn06Md1bWeiic0gx14nQ3W0XbDgCTHYP4d2QMxqhs30=; b=S5aAqRoNPd32xsOohM9PfgeSsMMbq2FuI03uPo7WC6yfsash5TtbXGNr OYY38GeOdbpgX4qj0td0Ay27uTD1RFVhqEx8EU6XSYgSPRF2ypYpv0crH vJrqIx7sRrPBv3VYxmFb4P3G5AOvZrpC2Ab5G68Vyi53sb/H5oAPTPaRb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8PAPGc31KQ/khL/2dsb2JhbABbgws4tRKHH4ERFnSCJQEBAQQBAQE1NgoRCxgJFg8JAwIBAgEVMAYBDAYCAQGIAQ3BSxMEjwOEOAEDmCKGR4tRgy47 X-IronPort-AV: E=Sophos;i="4.95,698,1384300800"; d="scan'208";a="4002805" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 10:28:43 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MAShvg028399; Wed, 22 Jan 2014 10:28:43 GMT Message-ID: <52DF9D5B.2060405@cisco.com> Date: Wed, 22 Jan 2014 11:28:43 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , Thomas Nadeau , "MIB Doctors (E-mail)" , eman mailing list References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52DF8186.3020705@bwijnen.net> In-Reply-To: <52DF8186.3020705@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:28:46 -0000 On 22/01/2014 09:29, Bert Wijnen (IETF) wrote: > > > On 21/01/14 21:52, Thomas Nadeau wrote: >> 4) The EMAN WG and MIB Doctors consensus was to root all MIB >> modules under transmission, rather than under the single OID >> energyMIB. These modules still use the older approach, so please >> correct them. > > EMAN MIB Modules under "transmission" ???? > That sounds weird to me. I would think under mib-2 mib-2 is what's currently in the draft, like the ENTITY-MIB v4, RFC 6933. Regards, Benoit > > Bert > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From dromasca@avaya.com Wed Jan 22 02:53:09 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF0A1A0429 for ; Wed, 22 Jan 2014 02:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 LM3Iavl6-Anm for ; Wed, 22 Jan 2014 02:53:07 -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 294BE1A0424 for ; Wed, 22 Jan 2014 02:53:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIPAGCi31LGmAcV/2dsb2JhbABbgkcjIThWtDyHH4ERFnSCJQEBAQEDAQEBDxtBCwwEAgEGAg0BAwQBAQsWBwcnCxQJCAIEAQ0FCAEZh2MBDIknkTCmexeOGhACAR4tBAYBBoMegRQEnxGLKYMtgio X-IronPort-AV: E=Sophos;i="4.95,698,1384318800"; d="scan'208,217";a="39917454" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Jan 2014 05:53:05 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 22 Jan 2014 05:42:55 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 11:53:00 +0100 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "adrian@olddog.co.uk" , "'Bert Wijnen (IETF)'" , "'Thomas Nadeau'" Thread-Topic: [MIB-DOCTORS] Why is this MIB module read-write? Thread-Index: AQHPFgb7ObD7bbLL6EGX+W7K2ioreJqO3sMAgAAR4aCAAJhwgP//v5xwgABWAYD//5/hgIAAhqKAgAC3AgCAABS98A== Date: Wed, 22 Jan 2014 10:52:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243D46E9@AZ-FFEXMB04.global.avaya.com> References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> <52DF9D02.6070306@cisco.com> In-Reply-To: <52DF9D02.6070306@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA243D46E9AZFFEXMB04globa_" MIME-Version: 1.0 Cc: "'MIB Doctors \(E-mail\)'" Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:53:09 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA243D46E9AZFFEXMB04globa_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, As we seem to have agreed with the principle let me throw a few comments ab= out the proposed text: "The OPS Area henceforth strongly discourages the pursuit of writable SNMP = MIBs for configuration purposes by working groups except in cases of clear = utility and overwhelming consensus to do so. In all other cases, we recomme= nd the use of NETCONF/YANG IETF standards for configuration, specifically i= n new charters." - We are preaching to the word to avoid using =91SNMP MIBs=92 so l= et us be consistent with ourselves :) s/SNMP MIBs/SNMP MIB objects/ - An example of clear utility would be useful. I am thinking for e= xample the case of MIB objects that enable/disable notifications. If these = are the only writeable objects in a MIB module, I do not think we should re= commend supporting NETCONF/YANG just for enabling/disabling notifications - I am reluctant to define a new class of consensus here and I do = not know what =91overwhelming consensus=92 means. Let us drop this. As we say =91The OPS Area =85=92 I believe that this statement needs to go = through some consensus call on the OPS Area or opsawg mail list. I have no problem with posting this first on the MIB doctors wiki, but runn= ing it later as an IESG statement would send a stronger and more visible si= gnal to all WGs in the IETF. Regards, Dan From: Benoit Claise [mailto:bclaise@cisco.com] Sent: =E9=E5=ED =E3 22 =E9=F0=E5=E0=F8 2014 12:27 To: adrian@olddog.co.uk; 'Bert Wijnen (IETF)'; 'Thomas Nadeau'; Romascanu, = Dan (Dan) Cc: 'MIB Doctors (E-mail)' Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? Adrian, All, As expected and desired, this generated some good discussions (also in a di= fferent email thread between the MIB doctors) So we went - from "SNMPSet is dead", as a comment to make people react - to "SNMPSet is dead?" - to "we do not require writable MIB modules" - A statement such as "The OPS Area henceforth strongly discourages the pur= suit of writable SNMP MIBs by working groups except in cases of clear utili= ty and overwhelming consensus to do so. In all other cases, we recommend th= e use of tools such as Netconf/Netmod for configuration." - to "do not use writeable objects for configuration in MIB modules" We could go with an IESG statement, but I propose to make it easy to start = with, with a statement on the MIB doctors page (http://www.ietf.org/iesg/di= rectorate/mib-doctors.html) "The OPS Area henceforth strongly discourages the pursuit of writable SNMP = MIBs for configuration purposes by working groups except in cases of clear = utility and overwhelming consensus to do so. In all other cases, we recomme= nd the use of NETCONF/YANG IETF standards for configuration, specifically i= n new charters." - I added "for configuration". SNMPSet could potentially be used for action= . - I removed "such as" in "tools such as Netconf/Netmod for configuration." = Not sure what you're referring to here Tom - I added "specifically in new charters." Right now, there are read-write M= IB modules in EMAN. It would not be a sound idea to say now, specifically w= hen documents went through LC: stop what you're doing, recharter to do YANG= modules. What's key in EMAN is that an Information Model has been specifie= d part of the framework. Feedback? Regards, Benoit (speaking as not a MIB Doctor) I like that very much, thanks for the words Tom. Benoit, do you think this is a big enough issue that we should make it an I= ESG statement? Or do you just want to run it through the OPSAWG in some way? A -----Original Message----- From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] Sent: 21 January 2014 15:30 To: Thomas Nadeau; Romascanu, Dan (Dan) Cc: MIB Doctors (E-mail); Farrel Adrian Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? sounds good to me Bert On 21/01/14 16:14, Thomas Nadeau wrote: Agreed. Something like, "The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs by working groups except in cases of clea= r utility and overwhelming consensus to do so. In all other cases, we recomme= nd the use of tools such as Netconf/Netmod for configuration." --Tom Hi Tom, This is exactly my point. I think that we should not only say 'do not do Sets using SNMP'. We should also say what to do instead. Regards, Dan -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] .... I do agree that guidance needs to be issues to developers and especially IETF WGs on this matter. --Tom _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors . --_000_9904FB1B0159DA42B0B887B7FA8119CA243D46E9AZFFEXMB04globa_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

As we seem to have agreed= with the principle let me throw a few comments about the proposed text:

 <= /p>

"The OPS Area henceforth strongly discourages t= he pursuit of writable SNMP MIBs for configuration purposes by working grou= ps except in cases of clear utility and overwhelming consensus to do so. In= all other cases, we recommend the use of NETCONF/YANG IETF standards for configuration, specifically in new char= ters."

 <= /p>

- = ;         We are preaching to the word to avoid using =91SNMP MIBs=92 so let = us be consistent with ourselves J s/SNMP MIBs/SNMP MIB objects/

- = ;         An example of clear utility would be useful. I am thinking for exam= ple the case of MIB objects that enable/disable notifications. If these are the only writeable objects in a MIB module, I do not think we= should recommend supporting NETCONF/YANG just for enabling/disabling notif= ications

- = ;         I am reluctant to define a new class of consensus here and I do not= know what =91overwhelming consensus=92 means. Let us drop this.

 <= /p>

As we say =91The OPS Area= =85=92 I believe that this statement needs to go through some consensus ca= ll on the OPS Area or opsawg mail list.

 <= /p>

I have no problem with po= sting this first on the MIB doctors wiki, but running it later as an IESG s= tatement would send a stronger and more visible signal to all WGs in the IETF.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: =E9=E5=ED =E3 22 =E9=F0=E5=E0=F8<= /span><= /span> 2014 12:27
To: adrian@olddog.co.uk; 'Bert Wijnen (IETF)'; 'Thomas Nadeau'; Roma= scanu, Dan (Dan)
Cc: 'MIB Doctors (E-mail)'
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

 

Adrian, All,

As expected and desired, this generated some good discussions (also in a di= fferent email thread between the MIB doctors)

So we went
- from "SNMPSet is dead", as a comment to make people react
- to "SNMPSet is dead?"
- to "we do not require writable MIB modules"
- A statement such as "The OPS Area henceforth strongly discourages th= e pursuit of writable SNMP MIBs by working groups except in cases of clear = utility and overwhelming consensus to do so. In all other cases, we recomme= nd the use of tools such as Netconf/Netmod for configuration."
- to "do not use writeable objects for configuration in MIB mod= ules"

We could go with an IESG statement, but I propose to make it easy to start = with, with a statement on the MIB doctors page (http://www.ietf.org/iesg/directorate= /mib-doctors.html)

"The OPS Area henceforth strongly discourages t= he pursuit of writable SNMP MIBs for configuration purposes by working grou= ps except in cases of clear utility and overwhelming consensus to do so. In= all other cases, we recommend the use of NETCONF/YANG IETF standards for configuration, specifically in new char= ters."

- I added "for c= onfiguration". SNMPSet could potentially be used for action.
- I removed "such as" in "tools such as Netconf/Netmod for c= onfiguration." Not sure what you're referring to here Tom
- I added "specifically in new charters." Right now, there are re= ad-write MIB modules in EMAN. It would not be a sound idea to say now, spec= ifically when documents went through LC: stop what you're doing, recharter = to do YANG modules. What's key in EMAN is that an Information Model has been specified part of the framework.

Feedback?

Regards, Benoit

(speaking as not a MIB Doctor)
 
I like that very much, thanks for the words Tom.
 
Benoit, do you think this is a big enough issue that we should make it=
 an IESG
statement?
Or do you just want to run it through the OPSAWG in some way?
 
A
 
-----Original Message-----
From: Bert Wijnen (IETF) [mail=
to:bertietf@bwijnen.net]
Sent: 21 January 2014 15:30
To: Thomas Nadeau; Romascanu, Dan (Dan)
Cc: MIB Doctors (E-mail); Farrel Adrian
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
 
sounds good to me
 
Bert
 
On 21/01/14 16:14, Thomas Nadeau wrote:
 
    Agreed. Something like, "The OPS Area hencefor=
th strongly discourages
the pursuit of writable SNMP MIBs by working groups except in cases of=
 clear
utility and overwhelming consensus to do so. In all other cases, we re=
commend
the use of tools such as Netconf/Netmod for configuration."<=
/o:p>
 
    --Tom
 
 
Hi Tom,
 
This is exactly my point. I think that we should not only say 'do not =
do
Sets
using SNMP'. We should also say what to do instead.
 
Regards,
 
Dan
 
 
-----Original Message-----
From: Thomas Nadeau [mailto=
:tnadeau@lucidvision.com]
 
....
 
       I do agree that guidance needs to=
 be issues to developers and
especially IETF WGs on this matter.
 
       --Tom
 
 
 
 
 
 
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org<=
/o:p>
https://=
www.ietf.org/mailman/listinfo/mib-doctors
 
 
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org<=
/o:p>
https://=
www.ietf.org/mailman/listinfo/mib-doctors
.
 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA243D46E9AZFFEXMB04globa_-- From tnadeau@lucidvision.com Wed Jan 22 05:07:45 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6641A00F2; Wed, 22 Jan 2014 05:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 CkaZ_k6N7tRm; Wed, 22 Jan 2014 05:07:44 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFA1A00F8; Wed, 22 Jan 2014 05:07:44 -0800 (PST) Received: from [192.168.1.103] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8D0B826C282C; Wed, 22 Jan 2014 08:07:43 -0500 (EST) References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52DF8186.3020705@bwijnen.net> Mime-Version: 1.0 (1.0) In-Reply-To: <52DF8186.3020705@bwijnen.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3E6D350F-AB46-4992-A3E3-D2CBDCCD82EE@lucidvision.com> X-Mailer: iPad Mail (11B554a) From: "Thomas D. Nadeau" Date: Wed, 22 Jan 2014 08:07:43 -0500 To: "Bert Wijnen (IETF)" Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:07:45 -0000 That is a good catch Bert. You are right - its mib-2! --Tom > On Jan 22, 2014, at 3:29 AM, "Bert Wijnen (IETF)" w= rote: >=20 >=20 >=20 >> On 21/01/14 21:52, Thomas Nadeau wrote: >> 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules u= nder transmission, rather than under the single OID energyMIB. These modules= still use the older approach, so please correct them. >=20 > EMAN MIB Modules under "transmission" ???? > That sounds weird to me. I would think under mib-2 >=20 > Bert >=20 From tnadeau@lucidvision.com Wed Jan 22 05:08:59 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7791A00F8; Wed, 22 Jan 2014 05:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 Cq7rAGOUW9Do; Wed, 22 Jan 2014 05:08:58 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2198B1A00F2; Wed, 22 Jan 2014 05:08:58 -0800 (PST) Received: from [192.168.1.103] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8F34A26C284A; Wed, 22 Jan 2014 08:08:57 -0500 (EST) References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52DF8186.3020705@bwijnen.net> <52DF9D5B.2060405@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52DF9D5B.2060405@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: "Thomas D. Nadeau" Date: Wed, 22 Jan 2014 08:08:57 -0500 To: Benoit Claise Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:08:59 -0000 Yes mib-2 is correct. I was confused on that one. > On Jan 22, 2014, at 5:28 AM, Benoit Claise wrote: >=20 >> On 22/01/2014 09:29, Bert Wijnen (IETF) wrote: >>=20 >>=20 >>> On 21/01/14 21:52, Thomas Nadeau wrote: >>> 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules u= nder transmission, rather than under the single OID energyMIB. These modules= still use the older approach, so please correct them. >>=20 >> EMAN MIB Modules under "transmission" ???? >> That sounds weird to me. I would think under mib-2 > mib-2 is what's currently in the draft, like the ENTITY-MIB v4, RFC 6933. >=20 > Regards, Benoit >>=20 >> Bert >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >=20 >=20 From aldrin.ietf@gmail.com Wed Jan 22 05:20:40 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4561A00F7 for ; Wed, 22 Jan 2014 05:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] 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 Vgr9v1cEASQS for ; Wed, 22 Jan 2014 05:20:36 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 31F8F1A00DA for ; Wed, 22 Jan 2014 05:20:36 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so373074pab.18 for ; Wed, 22 Jan 2014 05:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EP7c6DteeOP+Bt7s2cwM1vBfYv/d0L6B5JEQF3gPb9o=; b=QHRV7yqkhrtrabhGjRShKmfraITydguujd6QLE8NpXz8YPvfl1TYwAugqkAf5JwZGX R8mot7u1BwVtOhwZ/92V+sKzxWFCFrdONUqb/KCS81kHixhbqK30FHJlm70YUXKYQdAO yX4iaVOCZQzVPnNAY+PjWGO2L729ISMnzTvU1p+bmi1REVIaqgskP6ZyQ6hWfsQPME1R ef/+My8AQaVATFuVJ4efIesKirmwE48Ww2tAynfzypifbPmey8JKNpn364VkenOYUgg8 agZNacsKRmvjIpx0Afd/1Ee8cfbu/2dQsnrjv/d2tlGnQ9IeLIXtIQwbPEk6aBlrjFUr JFQA== X-Received: by 10.66.253.33 with SMTP id zx1mr1635538pac.28.1390396835821; Wed, 22 Jan 2014 05:20:35 -0800 (PST) Received: from [192.168.1.6] (c-107-3-154-8.hsd1.ca.comcast.net. [107.3.154.8]) by mx.google.com with ESMTPSA id yz5sm47449792pac.9.2014.01.22.05.20.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 05:20:34 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DDAAADB7-C53F-4032-BC5A-46D519B932F1" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sam Aldrin In-Reply-To: <52DD540F.80302@cisco.com> Date: Wed, 22 Jan 2014 05:20:33 -0800 Message-Id: <885534D3-2F14-4F0A-829B-70B241607D10@gmail.com> References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> <52DCCF25.9010405@cisco.com> <084201cf15c4$6c644e40$452ceac0$@olddog.co.uk> <8512CF0E-FFF2-4ADC-BC6E-12031FBF0D76@lucidvision.com> <52DD540F.80302@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: Kannan Sampath , "MIB Doctors \(E-mail\)" , Venkatesan Mahalingam , Farrel Adrian , mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org, Loa Andersson Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:20:40 -0000 --Apple-Mail=_DDAAADB7-C53F-4032-BC5A-46D519B932F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Benoit, Catching up on email as I returned from vacation just now. See my comments inline. -sam On Jan 20, 2014, at 8:51 AM, Benoit Claise wrote: > On 20/01/2014 17:25, Thomas Nadeau wrote: >> On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel = wrote: >>=20 >>> What I think Loa is saying is "help!" >>>=20 >>> The MIB Doctor review was great and found a large number of issues = with the >>> document. >>> Yet, when the document reached the AD for review there were still a = significant >>> number of issues with the MIB modules. >>>=20 >>> I don't think that the MIB Doctor can be expected to review and = re-review every >>> document until it is perfect (they are welcome to, and we are = delighted when >>> they do, but they are human and they have day jobs), and I believe = that >>> sometimes it is simply not possible to find all issues in the first = review >>> because one set of problems obscure another set. >>>=20 >>> Loa has forwarded a mail taken from part way through the email = thread. A number >>> of issues with the ANS.1 have been fixed by now, and this particular = email was >>> edited down to remove the technical issues and just leave the = "political" ones. >>>=20 >>> FWIW I have no issue with the level of review given to this document = by the MIB >>> Doctor. I do have an issue with the level of quality of this = document as it came >>> from the WG to first the MIB Doctor and then to me. >>>=20 >>> It needs to be understood, IMHO, that people writing MIB modules are = supposed to >>> understand roughly what they are doing and to use the MIB doctors to = verify the >>> quality and catch a few missed issues. It is not the MIB Doctor's = job to provide >>> the ASN.1 for the authors! >>>=20 >>> Loa is (rightly) wondering how he can get this sort of document up = to quality >>> when the WG is not very interested, the level of MIB clue in the WG = is low, and >>> the MIB Doctors are not super-heroes with days or weeks of spare = time. I have no >>> answer to that question except "Why do we keep writing write-access = MIB >>> modules?" >> I have made my opinion very clear on this in the past, and in = the case of this MIB the same holds true: I think the read-write stuff = is a giant waste of time. I objected to adding write capability to this = draft when the issue came up. At the time I predicted that based on past = experience, that we would waste hours upon hours on getting the write = capabilities correct for what is in effect a very simple MIB module that = should have taken a couple of months to complete in read-only format. = Look where we are? Why don't we save ourselves a lot of time and effort = going and make this read-only? Its very clear that nearly no one in = operations land uses writable MIBs. Why does the IETF continue to waste = its time with this? The world has moved forward, so we should too. > Let me it clear. IMO, SNMPSet is dead. %sam - Understand that not many are interested in SNMP Set. Dead is = stronger term as it is still being used (I know it is all SDN these days = :D) > During one of our last Ciscolive show (a big event with thousands of = participants), I went to most of my NMS partners, asking about SNMPset. = None are using SNMPSet. The only exception is a proprietary OPS feature = called IP SLA. > Now, if one WG wants to have read-write, that's also fine with me. %sam - Well if that is the case, why is Cisco still pushing SNMP write = option in the MIB? Refer = http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?include_text=3D1= In regards to this TP mib, we are having =91write=92 option only to few = scalar objects, which are OAM ID=92s like ICC ID, Node ID etc. Rest of = the MIB and extensions are just read only. -sam >=20 > Regards, Benoit >>=20 >> I will also point out something apropos to Loa's comment of a = lack of interest in reviewing the document that out of the 4 or 5 people = that have actually worked on it, I believe that only 1 wanted write = capability. I am not an MPLS WG chair, so I didn't call consensus, but = to me, that is not consensus to embark on making something writable thus = signing the WG/editors/reviewers/etc... up to take on a huge amount of = additional effort for what amounts to very, very little return. >>=20 >> --Tom >>=20 >>=20 >>=20 >>=20 >>> Adrian >>>=20 >>>>> The working group, the authors and the mib-doctors have put in a >>>>> substantial amount of time and effort to get the document in = shape. >>>>>=20 >>>>> Not being a MIB-expert the shepherd have relied heavily on the >>>>> MIB-doctors. A process that worked well in the past. >>>>>=20 >>>>> Three different versions were iterated between the MIB-doctors and >>>>> the authors and updated according the comments from the = MIB-doctor. >>>>> This process ends by the MIB-doctor saying that it is OK to = request >>>>> publication. >>>>>=20 >>>>> I'm a bit lost - but will try to work with authors and MIB-doctors = to >>>>> get the document in shape. >>>> I'm not sure I understand your email, or to be more precise, what = you >>>> expect from the MIB doctor? >>>> I concluded that MIB doctors review was done on this document. >>>> = http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history >>>> Am I wrong? >>>>> Question to Adrian: Scanning through your comments I have the = impression >>>>> that the actual MIB-modules are more or less ok, but that the >>>>> informative text is what needs to be updated, right? >>>> I don't see any MIB related feedback in this email. >>>>=20 >>>> Regards, Benoit >>>>> I also notice that >>>>> the authors agreed to to a grammar review. >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >>>>>> ++Adrian and MIB doctors. >>>>>>=20 >>>>>> On Sunday, January 19, 2014, Venkatesan Mahalingam >>>>>> >>> > >>>>>> wrote: >>>>>>=20 >>>>>> Hi All, >>>>>>=20 >>>>>> As we have quite a few review comments from AD, we are = addressing >>>>>> them in the private mail thread below. >>>>>>=20 >>>>>>>> I think you should discuss with your document shepherd whether = to >>>>>> release the >>>>>>>> changes in batches as you go along, or wait for all the changes >>>>>> in one go. >>>>>>=20 >>>>>> *Loa:* How would you like to proceed? Shall we release the = changes >>>>>> in batches or all changes in one go? >>>>>>=20 >>>>>> As some of the authors are in vacation now, could not spend = much >>>>>> time for discussing the comments. Hopefully, we will make this >>>>>> document into good shape by end of this month. >>>>>>=20 >>>>>> *Adrian: *Thanks for your response. We(Authors) shall discuss >>>>>> further on your below comments and update you as early as = possible. >>>>>>=20 >>>>>>>> Is there a reason to have this discussion in private and = missing >>>>>> one of your >>>>>>>> co-authors? >>>>>> Nope. Tom's Juniper email was bouncing and later I forgot to = add him >>>>>> in the mail thread. It's my bad..;-) >>>>>>=20 >>>>>> -Venkat. >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> From: *Adrian Farrel* >>>>> 'cvml', 'adrian@olddog.co.uk');>> >>>>>> Date: Sun, Jan 19, 2014 at 10:24 AM >>>>>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >>>>>> To: Venkatesan Mahalingam >>>>> > >>>>>> Cc: Sam Aldrin >>>>> 'sam.aldrin@gmail.com');>>, Kannan Sampath = >>>>> > >>>>>>=20 >>>>>>=20 >>>>>> Hello, >>>>>> Sorry for the delay. >>>>>>=20 >>>>>> Is there a reason to have this discussion in private and = missing one >>>>>> of your >>>>>> co-authors? >>>>>> Don't forget that you'll need to explain o the working group = and >>>>>> your document >>>>>> shepherd what you have changed and why. >>>>>>=20 >>>>>> I have edited out the points where we have full agreement. >>>>>>=20 >>>>>> Thanks for the work so far. I think we have some more to do. >>>>>>=20 >>>>>> I think you should discuss with your document shepherd whether = to >>>>>> release the >>>>>> changes in batches as you go along, or wait for all the = changes in >>>>>> one go. >>>>>>=20 >>>>>> Cheers, >>>>>> Adrian >>>>>>=20 >>>>>>> It would be nice if someone could do a pass on this document for >>>>>>> English and format. It is not essential because the RFC Editor >>>>>> will >>>>>>> resolve these issues, but it is wise because the fewer changes >>>>>> the RFC >>>>>>> Editor makes, the less chance there is of an accidental error. >>>>>>> VM>> OK. >>>>>> Does "OK" mean that you agree with me that it would be nice, = but >>>>>> that nothing >>>>>> will happen? >>>>>>=20 >>>>>>> I see a contradiction in >>>>>>>=20 >>>>>>> In >>>>>>> particular, it describes managed objects of Tunnels, = Identifiers, >>>>>> Label >>>>>>> Switching Router and Textual conventions for Multiprotocol Label >>>>>>> Switching (MPLS) based Transport Profile (TP). These MIB modules >>>>>> extend >>>>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >>>>>>> operations, so the MPLS-TP name is not included in the MIB = module >>>>>> name. >>>>>>> Either the extensions are for MPLS-TP or they are not. Your >>>>>> second >>>>>>> sentence says they are for more general applicability, and I >>>>>> agree with >>>>>>> that. So why does the first sentence and the document title talk >>>>>> about >>>>>>> MPLS-TP? >>>>>>>=20 >>>>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title >>>>>> because we >>>>>>> develop this MIB module as part of IETF MPLS-TP project. >>>>>>> First sentence will be changed. >>>>>> I see the change and am now faced with "untraditional = networks" >>>>>> which I like >>>>>> even less. >>>>>>=20 >>>>>> I wish you could decide what this MIB module is for and = describe >>>>>> that. Note that >>>>>> this problem runs through the document where you talk about = objects >>>>>> and tables >>>>>> being for MPLS-TP tunnels, etc. >>>>>>=20 >>>>>>> I think the Introduction would be made more useful and >>>>>> relevant if it >>>>>>> described the purpose and content of this document. Currently >>>>>> it says >>>>>>> what the existing documents don't do (although even that is >>>>>> pretty >>>>>>> vague). >>>>>> You added a few words per the Abstract, but you didn't really = change >>>>>> the text. >>>>>> Can you say what function you are adding support for. That = would >>>>>> probably >>>>>> address my concern. >>>>>>=20 >>>>>> And you left in place... >>>>>>=20 >>>>>>> The existing Multiprotocol Label Switching (MPLS) Traffic >>>>>> Engineering >>>>>>> (TE) Management Information Base (MIB) [RFC3812] and Generalized >>>>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering >>>>>> Management >>>>>>> Information Base [RFC4802] do not support the transport network >>>>>>> requirements of NON-IP based management and static bidirectional >>>>>>> tunnels. >>>>>> ...which says what other documents don;t allow you to do, but = not >>>>>> what this >>>>>> document does. >>>>>>=20 >>>>>> Furthermore, I previously said... >>>>>>=20 >>>>>>> There is also an implication here that this MIB module supports >>>>>> non-IP >>>>>>> based management. I looked but didn't see any description of how >>>>>> to run >>>>>>> SNMP in the absence of IP. >>>>>> And I don't see any change for this. >>>>>> How does an SNMP MIB module support non-IP based management? >>>>>>=20 >>>>>>> It goes on... >>>>>>>=20 >>>>>>> These MIB modules should be used in conjunction with [RFC3812] >>>>>>> and companion document [RFC3813] for MPLS-TP tunnel >>>>>> configuration and >>>>>>> management. >>>>>>>=20 >>>>>>> What is an "MPLS-TP tunnel"? >>>>>>>=20 >>>>>>> VM>> This document mainly focuses on static bi-directional >>>>>> tunnel. >>>>>>> We'll update the introduction section to provide more details. >>>>>> I think you mean tunnels that are not set up by signaling? >>>>>> What does "mainly" mean? >>>>>>=20 >>>>>> You now have... >>>>>>=20 >>>>>> This document mainly focuses on static >>>>>> bidirectional MIB modules that should be used in = conjunction >>>>>> with >>>>>> [RFC3812] and companion document [RFC3813] for MPLS = Transport >>>>>> Profile >>>>>> (MPLS-TP) path configuration and management. >>>>>>=20 >>>>>> What is a "static bidirectional MIB module". >>>>>> What is an "MPLS-TP path"? How does it differ from an MPLS = path? >>>>>>=20 >>>>>>> Section 4 might have been an opportunity to provide the >>>>>> information I >>>>>>> think is missing from the Introduction. But unfortunately it >>>>>> repeats >>>>>>> some of the text form the Introduction and then gives a very >>>>>> scanty >>>>>>> description of the purpose of the work. >>>>>>>=20 >>>>>>> Here, however, I find the text >>>>>>>=20 >>>>>>> As the existing MPLS- >>>>>>> TE-STD-MIB is not sufficient to capture all the ch --Apple-Mail=_DDAAADB7-C53F-4032-BC5A-46D519B932F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Benoit,

Catching up on email as I = returned from vacation just now.

See my = comments inline.

-sam
On Jan 20, = 2014, at 8:51 AM, Benoit Claise <bclaise@cisco.com> = wrote:

On 20/01/2014 17:25, Thomas Nadeau = wrote:
On Jan 20, 2014:4:45 AM, at 4:45 AM, = Adrian Farrel <adrian@olddog.co.uk> = wrote:

What I think Loa is saying is = "help!"

The MIB Doctor review was great and found a large number = of issues with the
document.
Yet, when the document reached the AD = for review there were still a significant
number of issues with the = MIB modules.

I don't think that the MIB Doctor can be expected to = review and re-review every
document until it is perfect (they are = welcome to, and we are delighted when
they do, but they are human and = they have day jobs), and I believe that
sometimes it is simply not = possible to find all issues in the first review
because one set of = problems obscure another set.

Loa has forwarded a mail taken from = part way through the email thread. A number
of issues with the ANS.1 = have been fixed by now, and this particular email was
edited down to = remove the technical issues and just leave the "political" = ones.

FWIW I have no issue with the level of review given to this = document by the MIB
Doctor. I do have an issue with the level of = quality of this document as it came
from the WG to first the MIB = Doctor and then to me.

It needs to be understood, IMHO, that = people writing MIB modules are supposed to
understand roughly what = they are doing and to use the MIB doctors to verify the
quality and = catch a few missed issues. It is not the MIB Doctor's job to = provide
the ASN.1 for the authors!

Loa is (rightly) wondering = how he can get this sort of document up to quality
when the WG is not = very interested, the level of MIB clue in the WG is low, and
the MIB = Doctors are not super-heroes with days or weeks of spare time. I have = no
answer to that question except "Why do we keep writing = write-access MIB
modules?"
I have = made my opinion very clear on this in the past, and in the case of this = MIB the same holds true: I think the read-write stuff is a giant waste = of time. I objected to adding write capability to this draft when the = issue came up. At the time I predicted that based on past experience, = that we would waste hours upon hours on getting the write capabilities = correct for what is in effect a very simple MIB module that should have = taken a couple of months to complete in read-only format. Look where we = are? Why don't we save ourselves a lot of time and effort going and make = this read-only?  Its very clear that nearly no one in operations = land uses writable MIBs. Why does the IETF continue to waste its time = with this?  The world has moved forward, so we should = too.
Let me it clear. IMO, SNMPSet is = dead.
%sam - Understand that not many are = interested in SNMP Set. Dead is stronger term as it is still being used = (I know it is all SDN these days :D)
During one of our last Ciscolive show = (a big event with thousands of participants), I went to most of my NMS = partners, asking about SNMPset. None are using SNMPSet. The only = exception is a proprietary OPS feature called IP SLA.
Now, if one WG = wants to have read-write, that's also fine with = me.
%sam - Well if that is the case, why is Cisco = still pushing SNMP write option in the MIB? Refer http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?includ= e_text=3D1

In regards to this TP mib, we = are having =91write=92 option only to few scalar objects, which are OAM = ID=92s like ICC ID, Node ID etc. Rest of the MIB and extensions are just = read only.

-sam

Regards, Benoit

I will also point out something apropos to Loa's comment = of a lack of interest in reviewing the document that out of the 4 or 5 = people that have actually worked on it, I believe that only 1 wanted = write capability. I am not an MPLS WG chair, so I didn't call consensus, = but to me, that is not consensus to embark on making something writable = thus signing the WG/editors/reviewers/etc... up to take on a huge amount = of additional effort for what amounts to very, very little = return.

--Tom




Adrian

The working group, the authors and the mib-doctors have = put in a
substantial amount of time and effort to get the document in = shape.

Not being a MIB-expert the shepherd have relied heavily on = the
MIB-doctors. A process that worked well in the past.

Three = different versions were iterated between the MIB-doctors and
the = authors and updated according the comments from the MIB-doctor.
This = process ends by the MIB-doctor saying that it is OK to = request
publication.

I'm a bit lost - but will try to work = with authors and MIB-doctors to
get the document in = shape.
I'm not sure I understand your email, or to be = more precise, what you
expect from the MIB doctor?
I concluded = that MIB doctors review was done on this document.
http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-h= istory
Am I wrong?
Question to = Adrian: Scanning through your comments I have the impression
that the = actual MIB-modules are more or less ok, but that the
informative text = is what needs to be updated, right?
I don't see any MIB = related feedback in this email.

Regards, Benoit
I also notice that
the authors agreed to to a grammar = review.

/Loa

On 2014-01-20 04:40, Venkatesan Mahalingam = wrote:
++Adrian and MIB doctors.

On = Sunday, January 19, 2014, Venkatesan = Mahalingam
<venkat.mahalingams@gmail.com
<mailto:venkat.mahalingams@gmail.com>>
wrote:

   Hi= All,

   As we have quite a few review comments = from AD, we are addressing
   them in the private mail = thread below.

I= think you should discuss with your document shepherd whether = to
   release = the
changes in = batches as you go along, or wait for all the = changes
   in one = go.

   *Loa:* How would you like to proceed? Shall = we release the changes
   in batches or all changes in = one go?

   As some of the authors are in vacation = now, could not spend much
   time for discussing the = comments. Hopefully, we will make this
   document = into good shape by end of this month.

   *Adrian: = *Thanks for your response. We(Authors) shall = discuss
   further on your below comments and update = you as early as possible.

Is there a reason to have this discussion in private and = missing
   one of = your
co-authors?
   N= ope. Tom's Juniper email was bouncing and later I forgot to add = him
   in the mail thread. It's my = bad..;-)

   -Venkat.

   ------= ---- Forwarded message ----------
   From: *Adrian = Farrel* <adrian@olddog.co.uk = <javascript:_e({},
   'cvml', = 'adrian@olddog.co.uk');>>
   Date: Sun, Jan 19, = 2014 at 10:24 AM
   Subject: RE: AD review of = draft-ietf-mpls-tp-te-mib
   To: Venkatesan Mahalingam = <venkat.mahalingams@gmail.com
   <javascript:_e({}= , 'cvml', = 'venkat.mahalingams@gmail.com');>>
   Cc: Sam = Aldrin <sam.aldrin@gmail.com <javascript:_e({}, = 'cvml',
   'sam.aldrin@gmail.com');>>, Kannan = Sampath = <kannankvs@gmail.com
   <javascript:_e({}, = 'cvml', = 'kannankvs@gmail.com');>>


   Hello,
&nb= sp;  Sorry for the delay.

   Is there a = reason to have this discussion in private and missing = one
   of = your
   co-authors?
   Don't forget = that you'll need to explain o the working group = and
   your document
   shepherd = what you have changed and why.

   I have edited = out the points where we have full = agreement.

   Thanks for the work so far. I think = we have some more to do.

   I think you should = discuss with your document shepherd whether = to
   release the
   changes in = batches as you go along, or wait for all the changes = in
   one = go.

   Cheers,
   Adrian

It would be nice if someone could do a pass on = this document for
English and format. It is not essential because the = RFC Editor
will
resolve = these issues, but it is wise because the fewer = changes
   the RFC
Editor makes, the less chance there is of an accidental = error.
VM>> OK.
   Does "OK" = mean that you agree with me that it would be nice, = but
   that nothing
   will = happen?

I see a contradiction = in

In
particular, it describes managed objects of Tunnels, = Identifiers,
   Label
Switching Router and Textual conventions for Multiprotocol = Label
Switching (MPLS) based Transport Profile (TP). These MIB = modules
   extend
the existing MPLS MIB objects for both MPLS-TP and = Non-MPLS-TP
operations, so the MPLS-TP name is not included in the = MIB module
   name.
Either the extensions are for MPLS-TP or they are not. = Your
second
sentence says = they are for more general applicability, and = I
   agree with
that. So why does the first sentence and the document = title talk
   about
MPLS-TP?

VM>> Per Loa suggestion, we kept the = mpls-tp in the title
because we
develop this MIB module as part of IETF MPLS-TP = project.
First sentence will be = changed.
   I see the change and am now = faced with "untraditional networks"
   which I = like
   even less.

   I wish you = could decide what this MIB module is for and = describe
   that. Note that
   this = problem runs through the document where you talk about = objects
   and tables
   being for = MPLS-TP tunnels, etc.

I think the = Introduction would be made more useful and
relevant if = it
described the purpose and content of = this document. Currently
it says
what the existing documents don't do (although even that = is
pretty
vague).
   You added a few = words per the Abstract, but you didn't really = change
   the text.
   Can you say = what function you are adding support for. That = would
   probably
   address my = concern.

   And you left in = place...

The existing Multiprotocol = Label Switching (MPLS) = Traffic
Engineering
(TE) = Management Information Base (MIB) [RFC3812] and = Generalized
Multiprotocol Label Switching (GMPLS) Traffic = Engineering
Management
Information Base [RFC4802] do not support the transport = network
requirements of NON-IP based management and static = bidirectional
tunnels.
   ...which = says what other documents don;t allow you to do, but = not
   what this
   document = does.

   Furthermore, I previously = said...

There is also an implication = here that this MIB module = supports
   non-IP
based management. I looked but didn't see any description = of how
   to run
SNMP in the absence of = IP.
   And I don't see any change for = this.
   How does an SNMP MIB module support non-IP = based management?

It goes = on...

These MIB modules should be used in conjunction with = [RFC3812]
and companion document [RFC3813] for MPLS-TP = tunnel
configuration and
management.

What is an "MPLS-TP = tunnel"?

VM>> This document mainly focuses on static = bi-directional
tunnel.
We'll = update the introduction section to provide more = details.
   I think you mean tunnels that = are not set up by signaling?
   What does "mainly" = mean?

   You now = have...

        This = document mainly focuses on = static
        bidirectional = MIB modules that should be used in = conjunction
with
        [RF= C3812] and companion document [RFC3813] for MPLS = Transport
   Profile
     &n= bsp;  (MPLS-TP) path configuration and = management.

   What is a "static bidirectional MIB = module".
   What is an "MPLS-TP path"? How does it = differ from an MPLS path?

Section 4 = might have been an opportunity to provide = the
information I
think is = missing from the Introduction. But unfortunately = it
repeats
some of the text = form the Introduction and then gives a = very
scanty
description of = the purpose of the work.

Here, however, I find the text

As = the existing MPLS-
TE-STD-MIB is not sufficient to capture all the = ch

= --Apple-Mail=_DDAAADB7-C53F-4032-BC5A-46D519B932F1-- From bclaise@cisco.com Wed Jan 22 05:32:01 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423531A00FC for ; Wed, 22 Jan 2014 05:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.435 X-Spam-Level: X-Spam-Status: No, score=-9.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 nR7YhC-2UxZw for ; Wed, 22 Jan 2014 05:31:56 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id CD8EA1A00EF for ; Wed, 22 Jan 2014 05:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43936; q=dns/txt; s=iport; t=1390397514; x=1391607114; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ATKZ1nmy+XjeSU5ywwyZvhVtQ74wDcWl/ew/HVQUpsg=; b=cq6kEvmPgDyrmdstNRSy74hlJlhc4FyCs0hLYTWw4f0DD5txLxb+Jdic XRAsuMeuRSdzCiXhT0yk0t7N1jNSmE4gdYl/UGZjpbat3DgMnU5/slq5/ 8gb7pGtbQ7bKbcEytnhsZ6mGXw+nL32RAXgtGPMp4AndztC6jBcqKwb8z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8PAN3G31KQ/khN/2dsb2JhbABagkdEOIkxq2SHH4ESFnSCJQEBAQQaUQYIEAsRAwECAQkXAQYHDwIQJQkIBg0BBQIBAYdtAxENvBYNhVYUAwaMYoEyEAIBPhEHBoQyBJY2gWyBMoUVhhaFO4MuOw X-IronPort-AV: E=Sophos;i="4.95,699,1384300800"; d="scan'208,217";a="3343643" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2014 13:31:52 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0MDVpM1003289; Wed, 22 Jan 2014 13:31:51 GMT Message-ID: <52DFC847.30909@cisco.com> Date: Wed, 22 Jan 2014 14:31:51 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sam Aldrin References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> <52DCCF25.9010405@cisco.com> <084201cf15c4$6c644e40$452ceac0$@olddog.co.uk> <8512CF0E-FFF2-4ADC-BC6E-12031FBF0D76@lucidvision.com> <52DD540F.80302@cisco.com> <885534D3-2F14-4F0A-829B-70B241607D10@gmail.com> In-Reply-To: <885534D3-2F14-4F0A-829B-70B241607D10@gmail.com> Content-Type: multipart/alternative; boundary="------------000907020105050200020102" Cc: Kannan Sampath , "MIB Doctors \(E-mail\)" , Venkatesan Mahalingam , Farrel Adrian , mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org, Loa Andersson Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:32:01 -0000 This is a multi-part message in MIME format. --------------000907020105050200020102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sam, > Benoit, > > Catching up on email as I returned from vacation just now. > > See my comments inline. > > -sam > On Jan 20, 2014, at 8:51 AM, Benoit Claise > wrote: > >> On 20/01/2014 17:25, Thomas Nadeau wrote: >>> On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel >>> > wrote: >>> >>>> What I think Loa is saying is "help!" >>>> >>>> The MIB Doctor review was great and found a large number of issues >>>> with the >>>> document. >>>> Yet, when the document reached the AD for review there were still a >>>> significant >>>> number of issues with the MIB modules. >>>> >>>> I don't think that the MIB Doctor can be expected to review and >>>> re-review every >>>> document until it is perfect (they are welcome to, and we are >>>> delighted when >>>> they do, but they are human and they have day jobs), and I believe that >>>> sometimes it is simply not possible to find all issues in the first >>>> review >>>> because one set of problems obscure another set. >>>> >>>> Loa has forwarded a mail taken from part way through the email >>>> thread. A number >>>> of issues with the ANS.1 have been fixed by now, and this >>>> particular email was >>>> edited down to remove the technical issues and just leave the >>>> "political" ones. >>>> >>>> FWIW I have no issue with the level of review given to this >>>> document by the MIB >>>> Doctor. I do have an issue with the level of quality of this >>>> document as it came >>>> from the WG to first the MIB Doctor and then to me. >>>> >>>> It needs to be understood, IMHO, that people writing MIB modules >>>> are supposed to >>>> understand roughly what they are doing and to use the MIB doctors >>>> to verify the >>>> quality and catch a few missed issues. It is not the MIB Doctor's >>>> job to provide >>>> the ASN.1 for the authors! >>>> >>>> Loa is (rightly) wondering how he can get this sort of document up >>>> to quality >>>> when the WG is not very interested, the level of MIB clue in the WG >>>> is low, and >>>> the MIB Doctors are not super-heroes with days or weeks of spare >>>> time. I have no >>>> answer to that question except "Why do we keep writing write-access MIB >>>> modules?" >>> I have made my opinion very clear on this in the past, and in the >>> case of this MIB the same holds true: I think the read-write stuff >>> is a giant waste of time. I objected to adding write capability to >>> this draft when the issue came up. At the time I predicted that >>> based on past experience, that we would waste hours upon hours on >>> getting the write capabilities correct for what is in effect a very >>> simple MIB module that should have taken a couple of months to >>> complete in read-only format. Look where we are? Why don't we save >>> ourselves a lot of time and effort going and make this read-only? >>> Its very clear that nearly no one in operations land uses writable >>> MIBs. Why does the IETF continue to waste its time with this? The >>> world has moved forward, so we should too. >> Let me it clear. IMO, SNMPSet is dead. > %sam - Understand that not many are interested in SNMP Set. Dead is > stronger term as it is still being used I know, it's a bold statement. The MIB doctors are currently preparing the politically-correct statement. Stay tune. > (I know it is all SDN these days :D) >> During one of our last Ciscolive show (a big event with thousands of >> participants), I went to most of my NMS partners, asking about >> SNMPset. None are using SNMPSet. The only exception is a proprietary >> OPS feature called IP SLA. >> Now, if one WG wants to have read-write, that's also fine with me. > %sam - Well if that is the case, why is Cisco still pushing SNMP write > option in the MIB? Refer > http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?include_text=1 I'm not the Cisco CTO in charge of management. From time to time, I wish I was, but let's not go there :-) Regards ,Benoit > > In regards to this TP mib, we are having ‘write’ option only to few > scalar objects, which are OAM ID’s like ICC ID, Node ID etc. Rest of > the MIB and extensions are just read only. > > -sam >> >> Regards, Benoit >>> >>> I will also point out something apropos to Loa's comment of a lack >>> of interest in reviewing the document that out of the 4 or 5 people >>> that have actually worked on it, I believe that only 1 wanted write >>> capability. I am not an MPLS WG chair, so I didn't call consensus, >>> but to me, that is not consensus to embark on making something >>> writable thus signing the WG/editors/reviewers/etc... up to take on >>> a huge amount of additional effort for what amounts to very, very >>> little return. >>> >>> --Tom >>> >>> >>> >>> >>>> Adrian >>>> >>>>>> The working group, the authors and the mib-doctors have put in a >>>>>> substantial amount of time and effort to get the document in shape. >>>>>> >>>>>> Not being a MIB-expert the shepherd have relied heavily on the >>>>>> MIB-doctors. A process that worked well in the past. >>>>>> >>>>>> Three different versions were iterated between the MIB-doctors and >>>>>> the authors and updated according the comments from the MIB-doctor. >>>>>> This process ends by the MIB-doctor saying that it is OK to request >>>>>> publication. >>>>>> >>>>>> I'm a bit lost - but will try to work with authors and MIB-doctors to >>>>>> get the document in shape. >>>>> I'm not sure I understand your email, or to be more precise, what you >>>>> expect from the MIB doctor? >>>>> I concluded that MIB doctors review was done on this document. >>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history >>>>> Am I wrong? >>>>>> Question to Adrian: Scanning through your comments I have the >>>>>> impression >>>>>> that the actual MIB-modules are more or less ok, but that the >>>>>> informative text is what needs to be updated, right? >>>>> I don't see any MIB related feedback in this email. >>>>> >>>>> Regards, Benoit >>>>>> I also notice that >>>>>> the authors agreed to to a grammar review. >>>>>> >>>>>> /Loa >>>>>> >>>>>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >>>>>>> ++Adrian and MIB doctors. >>>>>>> >>>>>>> On Sunday, January 19, 2014, Venkatesan Mahalingam >>>>>>> >>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> As we have quite a few review comments from AD, we are addressing >>>>>>> them in the private mail thread below. >>>>>>> >>>>>>>>> I think you should discuss with your document shepherd whether to >>>>>>> release the >>>>>>>>> changes in batches as you go along, or wait for all the changes >>>>>>> in one go. >>>>>>> >>>>>>> *Loa:* How would you like to proceed? Shall we release the >>>>>>> changes >>>>>>> in batches or all changes in one go? >>>>>>> >>>>>>> As some of the authors are in vacation now, could not spend much >>>>>>> time for discussing the comments. Hopefully, we will make this >>>>>>> document into good shape by end of this month. >>>>>>> >>>>>>> *Adrian: *Thanks for your response. We(Authors) shall discuss >>>>>>> further on your below comments and update you as early as >>>>>>> possible. >>>>>>> >>>>>>>>> Is there a reason to have this discussion in private and missing >>>>>>> one of your >>>>>>>>> co-authors? >>>>>>> Nope. Tom's Juniper email was bouncing and later I forgot to >>>>>>> add him >>>>>>> in the mail thread. It's my bad..;-) >>>>>>> >>>>>>> -Venkat. >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: *Adrian Farrel* >>>>>> 'cvml', 'adrian@olddog.co.uk');>> >>>>>>> Date: Sun, Jan 19, 2014 at 10:24 AM >>>>>>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >>>>>>> To: Venkatesan Mahalingam >>>>>> > >>>>>>> Cc: Sam Aldrin >>>>>> 'sam.aldrin@gmail.com');>>, Kannan Sampath >>>>>> > >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> Sorry for the delay. >>>>>>> >>>>>>> Is there a reason to have this discussion in private and >>>>>>> missing one >>>>>>> of your >>>>>>> co-authors? >>>>>>> Don't forget that you'll need to explain o the working group and >>>>>>> your document >>>>>>> shepherd what you have changed and why. >>>>>>> >>>>>>> I have edited out the points where we have full agreement. >>>>>>> >>>>>>> Thanks for the work so far. I think we have some more to do. >>>>>>> >>>>>>> I think you should discuss with your document shepherd whether to >>>>>>> release the >>>>>>> changes in batches as you go along, or wait for all the >>>>>>> changes in >>>>>>> one go. >>>>>>> >>>>>>> Cheers, >>>>>>> Adrian >>>>>>> >>>>>>>> It would be nice if someone could do a pass on this document for >>>>>>>> English and format. It is not essential because the RFC Editor >>>>>>> will >>>>>>>> resolve these issues, but it is wise because the fewer changes >>>>>>> the RFC >>>>>>>> Editor makes, the less chance there is of an accidental error. >>>>>>>> VM>> OK. >>>>>>> Does "OK" mean that you agree with me that it would be nice, but >>>>>>> that nothing >>>>>>> will happen? >>>>>>> >>>>>>>> I see a contradiction in >>>>>>>> >>>>>>>> In >>>>>>>> particular, it describes managed objects of Tunnels, Identifiers, >>>>>>> Label >>>>>>>> Switching Router and Textual conventions for Multiprotocol Label >>>>>>>> Switching (MPLS) based Transport Profile (TP). These MIB modules >>>>>>> extend >>>>>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >>>>>>>> operations, so the MPLS-TP name is not included in the MIB module >>>>>>> name. >>>>>>>> Either the extensions are for MPLS-TP or they are not. Your >>>>>>> second >>>>>>>> sentence says they are for more general applicability, and I >>>>>>> agree with >>>>>>>> that. So why does the first sentence and the document title talk >>>>>>> about >>>>>>>> MPLS-TP? >>>>>>>> >>>>>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title >>>>>>> because we >>>>>>>> develop this MIB module as part of IETF MPLS-TP project. >>>>>>>> First sentence will be changed. >>>>>>> I see the change and am now faced with "untraditional networks" >>>>>>> which I like >>>>>>> even less. >>>>>>> >>>>>>> I wish you could decide what this MIB module is for and describe >>>>>>> that. Note that >>>>>>> this problem runs through the document where you talk about >>>>>>> objects >>>>>>> and tables >>>>>>> being for MPLS-TP tunnels, etc. >>>>>>> >>>>>>>> I think the Introduction would be made more useful and >>>>>>> relevant if it >>>>>>>> described the purpose and content of this document. Currently >>>>>>> it says >>>>>>>> what the existing documents don't do (although even that is >>>>>>> pretty >>>>>>>> vague). >>>>>>> You added a few words per the Abstract, but you didn't really >>>>>>> change >>>>>>> the text. >>>>>>> Can you say what function you are adding support for. That would >>>>>>> probably >>>>>>> address my concern. >>>>>>> >>>>>>> And you left in place... >>>>>>> >>>>>>>> The existing Multiprotocol Label Switching (MPLS) Traffic >>>>>>> Engineering >>>>>>>> (TE) Management Information Base (MIB) [RFC3812] and Generalized >>>>>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering >>>>>>> Management >>>>>>>> Information Base [RFC4802] do not support the transport network >>>>>>>> requirements of NON-IP based management and static bidirectional >>>>>>>> tunnels. >>>>>>> ...which says what other documents don;t allow you to do, but not >>>>>>> what this >>>>>>> document does. >>>>>>> >>>>>>> Furthermore, I previously said... >>>>>>> >>>>>>>> There is also an implication here that this MIB module supports >>>>>>> non-IP >>>>>>>> based management. I looked but didn't see any description of how >>>>>>> to run >>>>>>>> SNMP in the absence of IP. >>>>>>> And I don't see any change for this. >>>>>>> How does an SNMP MIB module support non-IP based management? >>>>>>> >>>>>>>> It goes on... >>>>>>>> >>>>>>>> These MIB modules should be used in conjunction with [RFC3812] >>>>>>>> and companion document [RFC3813] for MPLS-TP tunnel >>>>>>> configuration and >>>>>>>> management. >>>>>>>> >>>>>>>> What is an "MPLS-TP tunnel"? >>>>>>>> >>>>>>>> VM>> This document mainly focuses on static bi-directional >>>>>>> tunnel. >>>>>>>> We'll update the introduction section to provide more details. >>>>>>> I think you mean tunnels that are not set up by signaling? >>>>>>> What does "mainly" mean? >>>>>>> >>>>>>> You now have... >>>>>>> >>>>>>> This document mainly focuses on static >>>>>>> bidirectional MIB modules that should be used in conjunction >>>>>>> with >>>>>>> [RFC3812] and companion document [RFC3813] for MPLS >>>>>>> Transport >>>>>>> Profile >>>>>>> (MPLS-TP) path configuration and management. >>>>>>> >>>>>>> What is a "static bidirectional MIB module". >>>>>>> What is an "MPLS-TP path"? How does it differ from an MPLS path? >>>>>>> >>>>>>>> Section 4 might have been an opportunity to provide the >>>>>>> information I >>>>>>>> think is missing from the Introduction. But unfortunately it >>>>>>> repeats >>>>>>>> some of the text form the Introduction and then gives a very >>>>>>> scanty >>>>>>>> description of the purpose of the work. >>>>>>>> >>>>>>>> Here, however, I find the text >>>>>>>> >>>>>>>> As the existing MPLS- >>>>>>>> TE-STD-MIB is not sufficient to capture all the ch > --------------000907020105050200020102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sam,
Benoit,

Catching up on email as I returned from vacation just now.

See my comments inline.

-sam
On Jan 20, 2014, at 8:51 AM, Benoit Claise <bclaise@cisco.com> wrote:

On 20/01/2014 17:25, Thomas Nadeau wrote:
On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

What I think Loa is saying is "help!"

The MIB Doctor review was great and found a large number of issues with the
document.
Yet, when the document reached the AD for review there were still a significant
number of issues with the MIB modules.

I don't think that the MIB Doctor can be expected to review and re-review every
document until it is perfect (they are welcome to, and we are delighted when
they do, but they are human and they have day jobs), and I believe that
sometimes it is simply not possible to find all issues in the first review
because one set of problems obscure another set.

Loa has forwarded a mail taken from part way through the email thread. A number
of issues with the ANS.1 have been fixed by now, and this particular email was
edited down to remove the technical issues and just leave the "political" ones.

FWIW I have no issue with the level of review given to this document by the MIB
Doctor. I do have an issue with the level of quality of this document as it came
from the WG to first the MIB Doctor and then to me.

It needs to be understood, IMHO, that people writing MIB modules are supposed to
understand roughly what they are doing and to use the MIB doctors to verify the
quality and catch a few missed issues. It is not the MIB Doctor's job to provide
the ASN.1 for the authors!

Loa is (rightly) wondering how he can get this sort of document up to quality
when the WG is not very interested, the level of MIB clue in the WG is low, and
the MIB Doctors are not super-heroes with days or weeks of spare time. I have no
answer to that question except "Why do we keep writing write-access MIB
modules?"
I have made my opinion very clear on this in the past, and in the case of this MIB the same holds true: I think the read-write stuff is a giant waste of time. I objected to adding write capability to this draft when the issue came up. At the time I predicted that based on past experience, that we would waste hours upon hours on getting the write capabilities correct for what is in effect a very simple MIB module that should have taken a couple of months to complete in read-only format. Look where we are? Why don't we save ourselves a lot of time and effort going and make this read-only?  Its very clear that nearly no one in operations land uses writable MIBs. Why does the IETF continue to waste its time with this?  The world has moved forward, so we should too.
Let me it clear. IMO, SNMPSet is dead.
%sam - Understand that not many are interested in SNMP Set. Dead is stronger term as it is still being used
I know, it's a bold statement.
The MIB doctors are currently preparing the politically-correct statement.
Stay tune.
(I know it is all SDN these days :D)
During one of our last Ciscolive show (a big event with thousands of participants), I went to most of my NMS partners, asking about SNMPset. None are using SNMPSet. The only exception is a proprietary OPS feature called IP SLA.
Now, if one WG wants to have read-write, that's also fine with me.
%sam - Well if that is the case, why is Cisco still pushing SNMP write option in the MIB? Refer http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?include_text=1
I'm not the Cisco CTO in charge of management. From time to time, I wish I was, but let's not go there :-)

Regards ,Benoit

In regards to this TP mib, we are having ‘write’ option only to few scalar objects, which are OAM ID’s like ICC ID, Node ID etc. Rest of the MIB and extensions are just read only.

-sam

Regards, Benoit

I will also point out something apropos to Loa's comment of a lack of interest in reviewing the document that out of the 4 or 5 people that have actually worked on it, I believe that only 1 wanted write capability. I am not an MPLS WG chair, so I didn't call consensus, but to me, that is not consensus to embark on making something writable thus signing the WG/editors/reviewers/etc... up to take on a huge amount of additional effort for what amounts to very, very little return.

--Tom




Adrian

The working group, the authors and the mib-doctors have put in a
substantial amount of time and effort to get the document in shape.

Not being a MIB-expert the shepherd have relied heavily on the
MIB-doctors. A process that worked well in the past.

Three different versions were iterated between the MIB-doctors and
the authors and updated according the comments from the MIB-doctor.
This process ends by the MIB-doctor saying that it is OK to request
publication.

I'm a bit lost - but will try to work with authors and MIB-doctors to
get the document in shape.
I'm not sure I understand your email, or to be more precise, what you
expect from the MIB doctor?
I concluded that MIB doctors review was done on this document.
http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history
Am I wrong?
Question to Adrian: Scanning through your comments I have the impression
that the actual MIB-modules are more or less ok, but that the
informative text is what needs to be updated, right?
I don't see any MIB related feedback in this email.

Regards, Benoit
I also notice that
the authors agreed to to a grammar review.

/Loa

On 2014-01-20 04:40, Venkatesan Mahalingam wrote:
++Adrian and MIB doctors.

On Sunday, January 19, 2014, Venkatesan Mahalingam
<venkat.mahalingams@gmail.com
<mailto:venkat.mahalingams@gmail.com>>
wrote:

   Hi All,

   As we have quite a few review comments from AD, we are addressing
   them in the private mail thread below.

I think you should discuss with your document shepherd whether to
   release the
changes in batches as you go along, or wait for all the changes
   in one go.

   *Loa:* How would you like to proceed? Shall we release the changes
   in batches or all changes in one go?

   As some of the authors are in vacation now, could not spend much
   time for discussing the comments. Hopefully, we will make this
   document into good shape by end of this month.

   *Adrian: *Thanks for your response. We(Authors) shall discuss
   further on your below comments and update you as early as possible.

Is there a reason to have this discussion in private and missing
   one of your
co-authors?
   Nope. Tom's Juniper email was bouncing and later I forgot to add him
   in the mail thread. It's my bad..;-)

   -Venkat.

   ---------- Forwarded message ----------
   From: *Adrian Farrel* <adrian@olddog.co.uk <javascript:_e({},
   'cvml', 'adrian@olddog.co.uk');>>
   Date: Sun, Jan 19, 2014 at 10:24 AM
   Subject: RE: AD review of draft-ietf-mpls-tp-te-mib
   To: Venkatesan Mahalingam <venkat.mahalingams@gmail.com
   <javascript:_e({}, 'cvml', 'venkat.mahalingams@gmail.com');>>
   Cc: Sam Aldrin <sam.aldrin@gmail.com <javascript:_e({}, 'cvml',
   'sam.aldrin@gmail.com');>>, Kannan Sampath <kannankvs@gmail.com
   <javascript:_e({}, 'cvml', 'kannankvs@gmail.com');>>


   Hello,
   Sorry for the delay.

   Is there a reason to have this discussion in private and missing one
   of your
   co-authors?
   Don't forget that you'll need to explain o the working group and
   your document
   shepherd what you have changed and why.

   I have edited out the points where we have full agreement.

   Thanks for the work so far. I think we have some more to do.

   I think you should discuss with your document shepherd whether to
   release the
   changes in batches as you go along, or wait for all the changes in
   one go.

   Cheers,
   Adrian

It would be nice if someone could do a pass on this document for
English and format. It is not essential because the RFC Editor
will
resolve these issues, but it is wise because the fewer changes
   the RFC
Editor makes, the less chance there is of an accidental error.
VM>> OK.
   Does "OK" mean that you agree with me that it would be nice, but
   that nothing
   will happen?

I see a contradiction in

In
particular, it describes managed objects of Tunnels, Identifiers,
   Label
Switching Router and Textual conventions for Multiprotocol Label
Switching (MPLS) based Transport Profile (TP). These MIB modules
   extend
the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP
operations, so the MPLS-TP name is not included in the MIB module
   name.
Either the extensions are for MPLS-TP or they are not. Your
second
sentence says they are for more general applicability, and I
   agree with
that. So why does the first sentence and the document title talk
   about
MPLS-TP?

VM>> Per Loa suggestion, we kept the mpls-tp in the title
because we
develop this MIB module as part of IETF MPLS-TP project.
First sentence will be changed.
   I see the change and am now faced with "untraditional networks"
   which I like
   even less.

   I wish you could decide what this MIB module is for and describe
   that. Note that
   this problem runs through the document where you talk about objects
   and tables
   being for MPLS-TP tunnels, etc.

I think the Introduction would be made more useful and
relevant if it
described the purpose and content of this document. Currently
it says
what the existing documents don't do (although even that is
pretty
vague).
   You added a few words per the Abstract, but you didn't really change
   the text.
   Can you say what function you are adding support for. That would
   probably
   address my concern.

   And you left in place...

The existing Multiprotocol Label Switching (MPLS) Traffic
Engineering
(TE) Management Information Base (MIB) [RFC3812] and Generalized
Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management
Information Base [RFC4802] do not support the transport network
requirements of NON-IP based management and static bidirectional
tunnels.
   ...which says what other documents don;t allow you to do, but not
   what this
   document does.

   Furthermore, I previously said...

There is also an implication here that this MIB module supports
   non-IP
based management. I looked but didn't see any description of how
   to run
SNMP in the absence of IP.
   And I don't see any change for this.
   How does an SNMP MIB module support non-IP based management?

It goes on...

These MIB modules should be used in conjunction with [RFC3812]
and companion document [RFC3813] for MPLS-TP tunnel
configuration and
management.

What is an "MPLS-TP tunnel"?

VM>> This document mainly focuses on static bi-directional
tunnel.
We'll update the introduction section to provide more details.
   I think you mean tunnels that are not set up by signaling?
   What does "mainly" mean?

   You now have...

        This document mainly focuses on static
        bidirectional MIB modules that should be used in conjunction
with
        [RFC3812] and companion document [RFC3813] for MPLS Transport
   Profile
        (MPLS-TP) path configuration and management.

   What is a "static bidirectional MIB module".
   What is an "MPLS-TP path"? How does it differ from an MPLS path?

Section 4 might have been an opportunity to provide the
information I
think is missing from the Introduction. But unfortunately it
repeats
some of the text form the Introduction and then gives a very
scanty
description of the purpose of the work.

Here, however, I find the text

As the existing MPLS-
TE-STD-MIB is not sufficient to capture all the ch


--------------000907020105050200020102-- From aldrin.ietf@gmail.com Wed Jan 22 05:37:02 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE81A00F7 for ; Wed, 22 Jan 2014 05:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] 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 GUYh8UMU8f0w for ; Wed, 22 Jan 2014 05:36:58 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A60691A00EF for ; Wed, 22 Jan 2014 05:36:58 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id un15so391019pbc.18 for ; Wed, 22 Jan 2014 05:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hnUuLEZ8GufUhemrlTfm5VNoHut3+7tMw8741zobP9E=; b=epAwfXv06ui0jQ0mN37a9xyFI9AC+MekPBbmeoyHoZJZjgyPYgFq0qG8bnqTd+dUcH cP6Ib3Zi4YwT4AWfF9cFnP7NWSgUTf2Xqe44Gs3iD9NLNbpTCWDxBNquATKK9yqfwREH 3l9eq78hM9Le4bMhnVUXA74urGWv0c64glFFooMgbMdjVa59wiCb55jCQUi96W3xH/FC F54UmaC/5GrxfSMBgMTs0+3BVVL0xwzyxNyGdCYVZU++xxM9duDF0QNrEsUixwqU91Eu VlT+0GgVucGC1oICtxXWUqDoKJA1QXvM7QITIHbSrAIPOvq8UCdlaUDT0SRUIe39mTSg ATHg== X-Received: by 10.66.142.107 with SMTP id rv11mr1676972pab.17.1390397818246; Wed, 22 Jan 2014 05:36:58 -0800 (PST) Received: from [192.168.1.6] (c-107-3-154-8.hsd1.ca.comcast.net. [107.3.154.8]) by mx.google.com with ESMTPSA id yz5sm47635573pac.9.2014.01.22.05.36.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 05:36:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_04B286B1-AA80-403E-B138-D1698E7D137C" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sam Aldrin In-Reply-To: <52DFC847.30909@cisco.com> Date: Wed, 22 Jan 2014 05:36:55 -0800 Message-Id: <73509168-7B8F-47F9-99B2-FB49F6F2C5AD@gmail.com> References: <065201cf0410$6652e450$32f8acf0$@olddog.co.uk> <07ca01cf1543$bcd6a750$3683f5f0$@olddog.co.uk> <52DC93AE.7090000@pi.nu> <52DCCF25.9010405@cisco.com> <084201cf15c4$6c644e40$452ceac0$@olddog.co.uk> <8512CF0E-FFF2-4ADC-BC6E-12031FBF0D76@lucidvision.com> <52DD540F.80302@cisco.com> <885534D3-2F14-4F0A-829B-70B241607D10@gmail.com> <52DFC847.30909@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: Kannan Sampath , "MIB Doctors \(E-mail\)" , Venkatesan Mahalingam , Farrel Adrian , mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org, Loa Andersson Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:37:02 -0000 --Apple-Mail=_04B286B1-AA80-403E-B138-D1698E7D137C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Benoit, Thanks for the reply,. It would be great to have a cleat guideline or statement in regards to = SNMP as a whole :D Didn;t want to pick on you in regards to =91Cisco=92. Just pointing that = there indeed work happening in SNMP world with SET=92s and SDN hasn=92t = taken over yet :D -sam On Jan 22, 2014, at 5:31 AM, Benoit Claise wrote: > Sam, >> Benoit, >>=20 >> Catching up on email as I returned from vacation just now. >>=20 >> See my comments inline. >>=20 >> -sam >> On Jan 20, 2014, at 8:51 AM, Benoit Claise wrote: >>=20 >>> On 20/01/2014 17:25, Thomas Nadeau wrote: >>>> On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel = wrote: >>>>=20 >>>>> What I think Loa is saying is "help!" >>>>>=20 >>>>> The MIB Doctor review was great and found a large number of issues = with the >>>>> document. >>>>> Yet, when the document reached the AD for review there were still = a significant >>>>> number of issues with the MIB modules. >>>>>=20 >>>>> I don't think that the MIB Doctor can be expected to review and = re-review every >>>>> document until it is perfect (they are welcome to, and we are = delighted when >>>>> they do, but they are human and they have day jobs), and I believe = that >>>>> sometimes it is simply not possible to find all issues in the = first review >>>>> because one set of problems obscure another set. >>>>>=20 >>>>> Loa has forwarded a mail taken from part way through the email = thread. A number >>>>> of issues with the ANS.1 have been fixed by now, and this = particular email was >>>>> edited down to remove the technical issues and just leave the = "political" ones. >>>>>=20 >>>>> FWIW I have no issue with the level of review given to this = document by the MIB >>>>> Doctor. I do have an issue with the level of quality of this = document as it came >>>>> from the WG to first the MIB Doctor and then to me. >>>>>=20 >>>>> It needs to be understood, IMHO, that people writing MIB modules = are supposed to >>>>> understand roughly what they are doing and to use the MIB doctors = to verify the >>>>> quality and catch a few missed issues. It is not the MIB Doctor's = job to provide >>>>> the ASN.1 for the authors! >>>>>=20 >>>>> Loa is (rightly) wondering how he can get this sort of document up = to quality >>>>> when the WG is not very interested, the level of MIB clue in the = WG is low, and >>>>> the MIB Doctors are not super-heroes with days or weeks of spare = time. I have no >>>>> answer to that question except "Why do we keep writing = write-access MIB >>>>> modules?" >>>>=20 >>>> I have made my opinion very clear on this in the = past, and in the case of this MIB the same holds true: I think the = read-write stuff is a giant waste of time. I objected to adding write = capability to this draft when the issue came up. At the time I predicted = that based on past experience, that we would waste hours upon hours on = getting the write capabilities correct for what is in effect a very = simple MIB module that should have taken a couple of months to complete = in read-only format. Look where we are? Why don't we save ourselves a = lot of time and effort going and make this read-only? Its very clear = that nearly no one in operations land uses writable MIBs. Why does the = IETF continue to waste its time with this? The world has moved forward, = so we should too. >>> Let me it clear. IMO, SNMPSet is dead. >> %sam - Understand that not many are interested in SNMP Set. Dead is = stronger term as it is still being used > I know, it's a bold statement. > The MIB doctors are currently preparing the politically-correct = statement. > Stay tune. >> (I know it is all SDN these days :D) >>> During one of our last Ciscolive show (a big event with thousands of = participants), I went to most of my NMS partners, asking about SNMPset. = None are using SNMPSet. The only exception is a proprietary OPS feature = called IP SLA. >>> Now, if one WG wants to have read-write, that's also fine with me. >> %sam - Well if that is the case, why is Cisco still pushing SNMP = write option in the MIB? Refer = http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?include_text=3D1= > I'm not the Cisco CTO in charge of management. =46rom time to time, I = wish I was, but let's not go there :-) >=20 > Regards ,Benoit >>=20 >> In regards to this TP mib, we are having =91write=92 option only to = few scalar objects, which are OAM ID=92s like ICC ID, Node ID etc. Rest = of the MIB and extensions are just read only. >>=20 >> -sam >>>=20 >>> Regards, Benoit >>>>=20 >>>>=20 >>>> I will also point out something apropos to Loa's = comment of a lack of interest in reviewing the document that out of the = 4 or 5 people that have actually worked on it, I believe that only 1 = wanted write capability. I am not an MPLS WG chair, so I didn't call = consensus, but to me, that is not consensus to embark on making = something writable thus signing the WG/editors/reviewers/etc... up to = take on a huge amount of additional effort for what amounts to very, = very little return. >>>>=20 >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Adrian >>>>>=20 >>>>>>> The working group, the authors and the mib-doctors have put in a >>>>>>> substantial amount of time and effort to get the document in = shape. >>>>>>>=20 >>>>>>> Not being a MIB-expert the shepherd have relied heavily on the >>>>>>> MIB-doctors. A process that worked well in the past. >>>>>>>=20 >>>>>>> Three different versions were iterated between the MIB-doctors = and >>>>>>> the authors and updated according the comments from the = MIB-doctor. >>>>>>> This process ends by the MIB-doctor saying that it is OK to = request >>>>>>> publication. >>>>>>>=20 >>>>>>> I'm a bit lost - but will try to work with authors and = MIB-doctors to >>>>>>> get the document in shape. >>>>>> I'm not sure I understand your email, or to be more precise, what = you >>>>>> expect from the MIB doctor? >>>>>> I concluded that MIB doctors review was done on this document. >>>>>> = http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history >>>>>> Am I wrong? >>>>>>> Question to Adrian: Scanning through your comments I have the = impression >>>>>>> that the actual MIB-modules are more or less ok, but that the >>>>>>> informative text is what needs to be updated, right? >>>>>> I don't see any MIB related feedback in this email. >>>>>>=20 >>>>>> Regards, Benoit >>>>>>> I also notice that >>>>>>> the authors agreed to to a grammar review. >>>>>>>=20 >>>>>>> /Loa >>>>>>>=20 >>>>>>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote: >>>>>>>> ++Adrian and MIB doctors. >>>>>>>>=20 >>>>>>>> On Sunday, January 19, 2014, Venkatesan Mahalingam >>>>>>>> >>>>> > >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> As we have quite a few review comments from AD, we are = addressing >>>>>>>> them in the private mail thread below. >>>>>>>>=20 >>>>>>>>>> I think you should discuss with your document shepherd = whether to >>>>>>>> release the >>>>>>>>>> changes in batches as you go along, or wait for all the = changes >>>>>>>> in one go. >>>>>>>>=20 >>>>>>>> *Loa:* How would you like to proceed? Shall we release the = changes >>>>>>>> in batches or all changes in one go? >>>>>>>>=20 >>>>>>>> As some of the authors are in vacation now, could not spend = much >>>>>>>> time for discussing the comments. Hopefully, we will make = this >>>>>>>> document into good shape by end of this month. >>>>>>>>=20 >>>>>>>> *Adrian: *Thanks for your response. We(Authors) shall = discuss >>>>>>>> further on your below comments and update you as early as = possible. >>>>>>>>=20 >>>>>>>>>> Is there a reason to have this discussion in private and = missing >>>>>>>> one of your >>>>>>>>>> co-authors? >>>>>>>> Nope. Tom's Juniper email was bouncing and later I forgot to = add him >>>>>>>> in the mail thread. It's my bad..;-) >>>>>>>>=20 >>>>>>>> -Venkat. >>>>>>>>=20 >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: *Adrian Farrel* >>>>>>> 'cvml', 'adrian@olddog.co.uk');>> >>>>>>>> Date: Sun, Jan 19, 2014 at 10:24 AM >>>>>>>> Subject: RE: AD review of draft-ietf-mpls-tp-te-mib >>>>>>>> To: Venkatesan Mahalingam >>>>>>> > >>>>>>>> Cc: Sam Aldrin >>>>>>> 'sam.aldrin@gmail.com');>>, Kannan Sampath = >>>>>>> > >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hello, >>>>>>>> Sorry for the delay. >>>>>>>>=20 >>>>>>>> Is there a reason to have this discussion in private and = missing one >>>>>>>> of your >>>>>>>> co-authors? >>>>>>>> Don't forget that you'll need to explain o the working group = and >>>>>>>> your document >>>>>>>> shepherd what you have changed and why. >>>>>>>>=20 >>>>>>>> I have edited out the points where we have full agreement. >>>>>>>>=20 >>>>>>>> Thanks for the work so far. I think we have some more to do. >>>>>>>>=20 >>>>>>>> I think you should discuss with your document shepherd = whether to >>>>>>>> release the >>>>>>>> changes in batches as you go along, or wait for all the = changes in >>>>>>>> one go. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>>> It would be nice if someone could do a pass on this document = for >>>>>>>>> English and format. It is not essential because the RFC Editor >>>>>>>> will >>>>>>>>> resolve these issues, but it is wise because the fewer changes >>>>>>>> the RFC >>>>>>>>> Editor makes, the less chance there is of an accidental error. >>>>>>>>> VM>> OK. >>>>>>>> Does "OK" mean that you agree with me that it would be nice, = but >>>>>>>> that nothing >>>>>>>> will happen? >>>>>>>>=20 >>>>>>>>> I see a contradiction in >>>>>>>>>=20 >>>>>>>>> In >>>>>>>>> particular, it describes managed objects of Tunnels, = Identifiers, >>>>>>>> Label >>>>>>>>> Switching Router and Textual conventions for Multiprotocol = Label >>>>>>>>> Switching (MPLS) based Transport Profile (TP). These MIB = modules >>>>>>>> extend >>>>>>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP >>>>>>>>> operations, so the MPLS-TP name is not included in the MIB = module >>>>>>>> name. >>>>>>>>> Either the extensions are for MPLS-TP or they are not. Your >>>>>>>> second >>>>>>>>> sentence says they are for more general applicability, and I >>>>>>>> agree with >>>>>>>>> that. So why does the first sentence and the document title = talk >>>>>>>> about >>>>>>>>> MPLS-TP? >>>>>>>>>=20 >>>>>>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title >>>>>>>> because we >>>>>>>>> develop this MIB module as part of IETF MPLS-TP project. >>>>>>>>> First sentence will be changed. >>>>>>>> I see the change and am now faced with "untraditional = networks" >>>>>>>> which I like >>>>>>>> even less. >>>>>>>>=20 >>>>>>>> I wish you could decide what this MIB module is for and = describe >>>>>>>> that. Note that >>>>>>>> this problem runs through the document where you talk about = objects >>>>>>>> and tables >>>>>>>> being for MPLS-TP tunnels, etc. >>>>>>>>=20 >>>>>>>>> I think the Introduction would be made more useful and >>>>>>>> relevant if it >>>>>>>>> described the purpose and content of this document. Currently >>>>>>>> it says >>>>>>>>> what the existing documents don't do (although even that is >>>>>>>> pretty >>>>>>>>> vague). >>>>>>>> You added a few words per the Abstract, but you didn't = really change >>>>>>>> the text. >>>>>>>> Can you say what function you are adding support for. That = would >>>>>>>> probably >>>>>>>> address my concern. >>>>>>>>=20 >>>>>>>> And you left in place... >>>>>>>>=20 >>>>>>>>> The existing Multiprotocol Label Switching (MPLS) Traffic >>>>>>>> Engineering >>>>>>>>> (TE) Management Information Base (MIB) [RFC3812] and = Generalized >>>>>>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering >>>>>>>> Management >>>>>>>>> Information Base [RFC4802] do not support the transport = network >>>>>>>>> requirements of NON-IP based management and static = bidirectional >>>>>>>>> tunnels. >>>>>>>> ...which says what other documents don;t allow you to do, = but not >>>>>>>> what this >>>>>>>> document does. >>>>>>>>=20 >>>>>>>> Furthermore, I previously said... >>>>>>>>=20 >>>>>>>>> There is also an implication here that this MIB module = supports >>>>>>>> non-IP >>>>>>>>> based management. I looked but didn't see any description of = how >>>>>>>> to run >>>>>>>>> SNMP in the absence of IP. >>>>>>>> And I don't see any change for this. >>>>>>>> How does an SNMP MIB module support non-IP based management? >>>>>>>>=20 >>>>>>>>> It goes on... >>>>>>>>>=20 >>>>>>>>> These MIB modules should be used in conjunction with [RFC3812] >>>>>>>>> and companion document [RFC3813] for MPLS-TP tunnel >>>>>>>> configuration and >>>>>>>>> management. >>>>>>>>>=20 >>>>>>>>> What is an "MPLS-TP tunnel"? >>>>>>>>>=20 >>>>>>>>> VM>> This document mainly focuses on static bi-directional >>>>>>>> tunnel. >>>>>>>>> We'll update the introduction section to provide more details. >>>>>>>> I think you mean tunnels that are not set up by signaling? >>>>>>>> What does "mainly" mean? >>>>>>>>=20 >>>>>>>> You now have... >>>>>>>>=20 >>>>>>>> This document mainly focuses on static >>>>>>>> bidirectional MIB modules that should be used in = conjunction >>>>>>>> with >>>>>>>> [RFC3812] and companion document [RFC3813] for MPLS = Transport >>>>>>>> Profile >>>>>>>> (MPLS-TP) path configuration and management. >>>>>>>>=20 >>>>>>>> What is a "static bidirectional MIB module". >>>>>>>> What is an "MPLS-TP path"? How does it differ from an MPLS = path? >>>>>>>>=20 >>>>>>>>> Section 4 might have been an opportunity to provide the >>>>>>>> information I >>>>>>>>> think is missing from the Introduction. But unfortunately it >>>>>>>> repeats >>>>>>>>> some of the text form the Introduction and then gives a very >>>>>>>> scanty >>>>>>>>> description of the purpose of the work. >>>>>>>>>=20 >>>>>>>>> Here, however, I find the text >>>>>>>>>=20 >>>>>>>>> As the existing MPLS- >>>>>>>>> TE-STD-MIB is not sufficient to capture all the ch >>=20 >=20 >=20 --Apple-Mail=_04B286B1-AA80-403E-B138-D1698E7D137C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Benoit,

Thanks for the reply,.
It would be = great to have a cleat guideline or statement in regards to SNMP as a = whole :D

Didn;t want to pick on you in regards = to =91Cisco=92. Just pointing that there indeed work happening in SNMP = world with SET=92s and SDN hasn=92t taken over yet = :D

-sam
On Jan 22, 2014, at 5:31 = AM, Benoit Claise <bclaise@cisco.com> = wrote:

Sam,
Benoit,

Catching up on email as I = returned from vacation just now.

See my = comments inline.

-sam
On Jan 20, = 2014, at 8:51 AM, Benoit Claise <bclaise@cisco.com> = wrote:

On 20/01/2014 17:25, Thomas Nadeau = wrote:
On Jan 20, 2014:4:45 AM, at 4:45 AM, = Adrian Farrel <adrian@olddog.co.uk> = wrote:

What I think Loa is saying is = "help!"

The MIB Doctor review was great and found a large number = of issues with the
document.
Yet, when the document reached the AD = for review there were still a significant
number of issues with the = MIB modules.

I don't think that the MIB Doctor can be expected to = review and re-review every
document until it is perfect (they are = welcome to, and we are delighted when
they do, but they are human and = they have day jobs), and I believe that
sometimes it is simply not = possible to find all issues in the first review
because one set of = problems obscure another set.

Loa has forwarded a mail taken from = part way through the email thread. A number
of issues with the ANS.1 = have been fixed by now, and this particular email was
edited down to = remove the technical issues and just leave the "political" = ones.

FWIW I have no issue with the level of review given to this = document by the MIB
Doctor. I do have an issue with the level of = quality of this document as it came
from the WG to first the MIB = Doctor and then to me.

It needs to be understood, IMHO, that = people writing MIB modules are supposed to
understand roughly what = they are doing and to use the MIB doctors to verify the
quality and = catch a few missed issues. It is not the MIB Doctor's job to = provide
the ASN.1 for the authors!

Loa is (rightly) wondering = how he can get this sort of document up to quality
when the WG is not = very interested, the level of MIB clue in the WG is low, and
the MIB = Doctors are not super-heroes with days or weeks of spare time. I have = no
answer to that question except "Why do we keep writing = write-access MIB
modules?"
I have made my opinion very clear on this in the = past, and in the case of this MIB the same holds true: I think the = read-write stuff is a giant waste of time. I objected to adding write = capability to this draft when the issue came up. At the time I predicted = that based on past experience, that we would waste hours upon hours on = getting the write capabilities correct for what is in effect a very = simple MIB module that should have taken a couple of months to complete = in read-only format. Look where we are? Why don't we save ourselves a = lot of time and effort going and make this read-only?  Its very = clear that nearly no one in operations land uses writable MIBs. Why does = the IETF continue to waste its time with this?  The world has moved = forward, so we should too.
Let me it clear. IMO, SNMPSet = is dead.
%sam - Understand that not many are = interested in SNMP Set. Dead is stronger term as it is still being = used
I know, it's a bold statement.
The MIB = doctors are currently preparing the politically-correct = statement.
Stay tune.
(I know it is all SDN these days :D)
During one of our last Ciscolive = show (a big event with thousands of participants), I went to most of my = NMS partners, asking about SNMPset. None are using SNMPSet. The only = exception is a proprietary OPS feature called IP SLA.
Now, if one WG = wants to have read-write, that's also fine with = me.
%sam - Well if that is the case, why is Cisco = still pushing SNMP write option in the MIB? Refer http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?includ= e_text=3D1
I'm not the Cisco CTO in charge of = management. =46rom time to time, I wish I was, but let's not go there = :-)

Regards ,Benoit

In regards to this TP mib, we are = having =91write=92 option only to few scalar objects, which are OAM ID=92s= like ICC ID, Node ID etc. Rest of the MIB and extensions are just read = only.

-sam

Regards, Benoit

I will also point out something apropos to Loa's = comment of a lack of interest in reviewing the document that out of the = 4 or 5 people that have actually worked on it, I believe that only 1 = wanted write capability. I am not an MPLS WG chair, so I didn't call = consensus, but to me, that is not consensus to embark on making = something writable thus signing the WG/editors/reviewers/etc... up to = take on a huge amount of additional effort for what amounts to very, = very little return.

--Tom




Adrian

The working group, the authors and the mib-doctors have = put in a
substantial amount of time and effort to get the document in = shape.

Not being a MIB-expert the shepherd have relied heavily on = the
MIB-doctors. A process that worked well in the past.

Three = different versions were iterated between the MIB-doctors and
the = authors and updated according the comments from the MIB-doctor.
This = process ends by the MIB-doctor saying that it is OK to = request
publication.

I'm a bit lost - but will try to work = with authors and MIB-doctors to
get the document in = shape.
I'm not sure I understand your email, or to be = more precise, what you
expect from the MIB doctor?
I concluded = that MIB doctors review was done on this document.
http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-h= istory
Am I wrong?
Question to = Adrian: Scanning through your comments I have the impression
that the = actual MIB-modules are more or less ok, but that the
informative text = is what needs to be updated, right?
I don't see any MIB = related feedback in this email.

Regards, Benoit
I also notice that
the authors agreed to to a grammar = review.

/Loa

On 2014-01-20 04:40, Venkatesan Mahalingam = wrote:
++Adrian and MIB doctors.

On = Sunday, January 19, 2014, Venkatesan Mahalingam
<venkat.mahalingams@gmail.com<= /a>
<mailto:venkat.mahalingams= @gmail.com>>
wrote:

   Hi = All,

   As we have quite a few review comments = from AD, we are addressing
   them in the private mail = thread below.

I= think you should discuss with your document shepherd whether = to
   release = the
changes in = batches as you go along, or wait for all the = changes
   in one = go.

   *Loa:* How would you like to proceed? Shall = we release the changes
   in batches or all changes in = one go?

   As some of the authors are in vacation = now, could not spend much
   time for discussing the = comments. Hopefully, we will make this
   document = into good shape by end of this month.

   *Adrian: = *Thanks for your response. We(Authors) shall = discuss
   further on your below comments and update = you as early as possible.

Is there a reason to have this discussion in private and = missing
   one of = your
co-authors?
   N= ope. Tom's Juniper email was bouncing and later I forgot to add = him
   in the mail thread. It's my = bad..;-)

   -Venkat.

   ------= ---- Forwarded message ----------
   From: *Adrian = Farrel* <adrian@olddog.co.uk <javascript:_e({},
   = ;'cvml', 'adrian@olddog.co.uk');>>
=    Date: Sun, Jan 19, 2014 at 10:24 = AM
   Subject: RE: AD review of = draft-ietf-mpls-tp-te-mib
   To: Venkatesan Mahalingam = <venkat.mahalingams@gmail.com<= /a>
   <javascript:_e({}, 'cvml', = 'venkat.mahalingams@gmail.com');>>
   Cc: = Sam Aldrin <sam.aldrin@gmail.com <javascript:_e({}, = 'cvml',
   'sam.aldrin@gmail.com');>>, = Kannan Sampath <kannankvs@gmail.com
  = ; <javascript:_e({}, 'cvml', = 'kannankvs@gmail.com');>>


   Hello,   Sorry for the delay.

   Is = there a reason to have this discussion in private and missing = one
   of = your
   co-authors?
   Don't forget = that you'll need to explain o the working group = and
   your document
   shepherd = what you have changed and why.

   I have edited = out the points where we have full = agreement.

   Thanks for the work so far. I think = we have some more to do.

   I think you should = discuss with your document shepherd whether = to
   release the
   changes in = batches as you go along, or wait for all the changes = in
   one = go.

   Cheers,
   Adrian

It would be nice if someone could do a pass on = this document for
English and format. It is not essential because the = RFC Editor
will
resolve = these issues, but it is wise because the fewer = changes
   the RFC
Editor makes, the less chance there is of an accidental = error.
VM>> OK.
   Does "OK" = mean that you agree with me that it would be nice, = but
   that nothing
   will = happen?

I see a contradiction = in

In
particular, it describes managed objects of Tunnels, = Identifiers,
   Label
Switching Router and Textual conventions for Multiprotocol = Label
Switching (MPLS) based Transport Profile (TP). These MIB = modules
   extend
the existing MPLS MIB objects for both MPLS-TP and = Non-MPLS-TP
operations, so the MPLS-TP name is not included in the = MIB module
   name.
Either the extensions are for MPLS-TP or they are not. = Your
second
sentence says = they are for more general applicability, and = I
   agree with
that. So why does the first sentence and the document = title talk
   about
MPLS-TP?

VM>> Per Loa suggestion, we kept the = mpls-tp in the title
because we
develop this MIB module as part of IETF MPLS-TP = project.
First sentence will be = changed.
   I see the change and am now = faced with "untraditional networks"
   which I = like
   even less.

   I wish you = could decide what this MIB module is for and = describe
   that. Note that
   this = problem runs through the document where you talk about = objects
   and tables
   being for = MPLS-TP tunnels, etc.

I think the = Introduction would be made more useful and
relevant if = it
described the purpose and content of = this document. Currently
it says
what the existing documents don't do (although even that = is
pretty
vague).
   You added a few = words per the Abstract, but you didn't really = change
   the text.
   Can you say = what function you are adding support for. That = would
   probably
   address my = concern.

   And you left in = place...

The existing Multiprotocol = Label Switching (MPLS) = Traffic
Engineering
(TE) = Management Information Base (MIB) [RFC3812] and = Generalized
Multiprotocol Label Switching (GMPLS) Traffic = Engineering
Management
Information Base [RFC4802] do not support the transport = network
requirements of NON-IP based management and static = bidirectional
tunnels.
   ...which = says what other documents don;t allow you to do, but = not
   what this
   document = does.

   Furthermore, I previously = said...

There is also an implication = here that this MIB module = supports
   non-IP
based management. I looked but didn't see any description = of how
   to run
SNMP in the absence of = IP.
   And I don't see any change for = this.
   How does an SNMP MIB module support non-IP = based management?

It goes = on...

These MIB modules should be used in conjunction with = [RFC3812]
and companion document [RFC3813] for MPLS-TP = tunnel
configuration and
management.

What is an "MPLS-TP = tunnel"?

VM>> This document mainly focuses on static = bi-directional
tunnel.
We'll = update the introduction section to provide more = details.
   I think you mean tunnels that = are not set up by signaling?
   What does "mainly" = mean?

   You now = have...

        This = document mainly focuses on = static
        bidirectional = MIB modules that should be used in = conjunction
with
        [RF= C3812] and companion document [RFC3813] for MPLS = Transport
   Profile
     &n= bsp;  (MPLS-TP) path configuration and = management.

   What is a "static bidirectional MIB = module".
   What is an "MPLS-TP path"? How does it = differ from an MPLS path?

Section 4 = might have been an opportunity to provide = the
information I
think is = missing from the Introduction. But unfortunately = it
repeats
some of the text = form the Introduction and then gives a = very
scanty
description of = the purpose of the work.

Here, however, I find the text

As = the existing MPLS-
TE-STD-MIB is not sufficient to capture all the = ch




= --Apple-Mail=_04B286B1-AA80-403E-B138-D1698E7D137C-- From tnadeau@lucidvision.com Wed Jan 22 06:17:47 2014 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19FC1A00D9 for ; Wed, 22 Jan 2014 06:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 vC6PBNaGmeSj for ; Wed, 22 Jan 2014 06:17:45 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 04A881A00B6 for ; Wed, 22 Jan 2014 06:17:44 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0D03226C2D6F; Wed, 22 Jan 2014 09:17:44 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_DFAFAABE-A741-4002-B7C7-0EF235B4E55C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <52DF9D02.6070306@cisco.com> Date: Wed, 22 Jan 2014 09:17:43 -0500 Message-Id: <00CC5E4C-EA74-4F6E-8C41-89226A9B7045@lucidvision.com> References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> <52DF9D02.6070306@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: Farrel Adrian , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:17:47 -0000 --Apple-Mail=_DFAFAABE-A741-4002-B7C7-0EF235B4E55C Content-Type: multipart/alternative; boundary="Apple-Mail=_DC0226E4-9B50-48D9-AA93-3CEE779E9E27" --Apple-Mail=_DC0226E4-9B50-48D9-AA93-3CEE779E9E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 22, 2014:5:27 AM, at 5:27 AM, Benoit Claise = wrote: > Adrian, All, >=20 > As expected and desired, this generated some good discussions (also in = a different email thread between the MIB doctors) >=20 > So we went=20 > - from "SNMPSet is dead", as a comment to make people react > - to "SNMPSet is dead?"=20 > - to "we do not require writable MIB modules" > - A statement such as "The OPS Area henceforth strongly discourages = the pursuit of writable SNMP MIBs by working groups except in cases of = clear utility and overwhelming consensus to do so. In all other cases, = we recommend the use of tools such as Netconf/Netmod for configuration." > - to "do not use writeable objects for configuration in MIB modules" >=20 > We could go with an IESG statement, but I propose to make it easy to = start with, with a statement on the MIB doctors page = (http://www.ietf.org/iesg/directorate/mib-doctors.html) > "The OPS Area henceforth strongly discourages the pursuit of writable = SNMP MIBs for configuration purposes by working groups except in cases = of clear utility and overwhelming consensus to do so. In all other = cases, we recommend the use of NETCONF/YANG IETF standards for = configuration, specifically in new charters." > - I added "for configuration". SNMPSet could potentially be used for = action. > - I removed "such as" in "tools such as Netconf/Netmod for = configuration." Not sure what you're referring to here Tom > - I added "specifically in new charters." Right now, there are = read-write MIB modules in EMAN. It would not be a sound idea to say now, = specifically when documents went through LC: stop what you're doing, = recharter to do YANG modules. What's key in EMAN is that an Information = Model has been specified part of the framework. >=20 > Feedback? I think the statement is spot on. --Tom >=20 > Regards, Benoit >=20 >> (speaking as not a MIB Doctor) >>=20 >> I like that very much, thanks for the words Tom. >>=20 >> Benoit, do you think this is a big enough issue that we should make = it an IESG >> statement? >> Or do you just want to run it through the OPSAWG in some way? >>=20 >> A >>=20 >>> -----Original Message----- >>> From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] >>> Sent: 21 January 2014 15:30 >>> To: Thomas Nadeau; Romascanu, Dan (Dan) >>> Cc: MIB Doctors (E-mail); Farrel Adrian >>> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write? >>>=20 >>> sounds good to me >>>=20 >>> Bert >>>=20 >>> On 21/01/14 16:14, Thomas Nadeau wrote: >>>> Agreed. Something like, "The OPS Area henceforth strongly = discourages >>> the pursuit of writable SNMP MIBs by working groups except in cases = of clear >>> utility and overwhelming consensus to do so. In all other cases, we = recommend >>> the use of tools such as Netconf/Netmod for configuration." >>>> --Tom >>>>=20 >>>>=20 >>>>> Hi Tom, >>>>>=20 >>>>> This is exactly my point. I think that we should not only say 'do = not do >> Sets >>> using SNMP'. We should also say what to do instead. >>>>> Regards, >>>>>=20 >>>>> Dan >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>> .... >>>>>=20 >>>>>> I do agree that guidance needs to be issues to developers and >>>>>> especially IETF WGs on this matter. >>>>>>=20 >>>>>> --Tom >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>=20 >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> . >>=20 >=20 --Apple-Mail=_DC0226E4-9B50-48D9-AA93-3CEE779E9E27 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jan 22, 2014:5:27 AM, at 5:27 AM, Benoit Claise <bclaise@cisco.com> wrote:

Adrian, All,

As expected and desired, this generated some good discussions (also in a different email thread between the MIB doctors)

So we went
- from "SNMPSet is dead", as a comment to make people react
- to "SNMPSet is dead?"
- to "we do not require writable MIB modules"
- A statement such as "The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs by working groups except in cases of clear utility and overwhelming consensus to do so. In all other cases, we recommend the use of tools such as Netconf/Netmod for configuration."
- to "do not use writeable objects for configuration in MIB modules"

We could go with an IESG statement, but I propose to make it easy to start with, with a statement on the MIB doctors page (http://www.ietf.org/iesg/directorate/mib-doctors.html)
"The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIBs for configuration purposes by working groups except in cases of clear utility and overwhelming consensus to do so. In all other cases, we recommend the use of NETCONF/YANG IETF standards for configuration, specifically in new charters."
- I added "for configuration". SNMPSet could potentially be used for action.
- I removed "such as" in "tools such as Netconf/Netmod for configuration." Not sure what you're referring to here Tom
- I added "specifically in new charters." Right now, there are read-write MIB modules in EMAN. It would not be a sound idea to say now, specifically when documents went through LC: stop what you're doing, recharter to do YANG modules. What's key in EMAN is that an Information Model has been specified part of the framework.

Feedback?

I think the statement is spot on.

--Tom




Regards, Benoit

(speaking as not a MIB Doctor)

I like that very much, thanks for the words Tom.

Benoit, do you think this is a big enough issue that we should make it an IESG
statement?
Or do you just want to run it through the OPSAWG in some way?

A


-----Original Message-----
From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
Sent: 21 January 2014 15:30
To: Thomas Nadeau; Romascanu, Dan (Dan)
Cc: MIB Doctors (E-mail); Farrel Adrian
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

sounds good to me

Bert

On 21/01/14 16:14, Thomas Nadeau wrote:

	Agreed. Something like, "The OPS Area henceforth strongly discourages

the pursuit of writable SNMP MIBs by working groups except in cases of clear
utility and overwhelming consensus to do so. In all other cases, we recommend
the use of tools such as Netconf/Netmod for configuration."

	--Tom



Hi Tom,

This is exactly my point. I think that we should not only say 'do not do

Sets

using SNMP'. We should also say what to do instead.

Regards,

Dan



-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]

....


	I do agree that guidance needs to be issues to developers and
especially IETF WGs on this matter.

	--Tom



          

          

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors



        

      

      
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors
.



    

    

  





--Apple-Mail=_DC0226E4-9B50-48D9-AA93-3CEE779E9E27--

--Apple-Mail=_DFAFAABE-A741-4002-B7C7-0EF235B4E55C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS39MHAAoJEPcO+I7eiUJZoSQP/j73cggjaGaLGK0Hc6Za+ddI
v9xTi3Dyz51J301s1Ppq5is3k+xgNq4adc0oiRtN2elRCxDs2WevdNHxPwo3aAbK
kqNGR+vx5qn0Z50WRi8PcTkt37/A6E/cqyX2jDN7xusZkhdRtE1JWavC7VoxKfe2
Y+gb8VNgc84915B63/P8VMYe8Ry/PiVCw3/SXZuPddZyT2yxR7VfgMdohlGa6BUP
JFMLdtAgIIUL6tE4m/pP1T48m2FPgGh7ZBX44TmHj2mT4am9+aHyoECDzMFauB8N
kv6xxHFFapKXt9UFvlN94GHEBr8hSbrJfYCDCXL3TyM9KDFpHZlw94KdaTeqKYxn
QY0ugbAXqnvo53XUjtjHyvJsLcs5IQn4+ZF2uAI3xuoOQN2Uu2AwDo0sBxIctr+N
bGB+svRK16/LPUyc9dLCoPG09RgULEGjxVJA/Doua346vZiKNupUuvMltV7XkHqA
2pq65wLcgDztQz/YR0d1Lt50cueyibjf1fTGlrg+gGNi36L1lORGq4++QwlO26ER
6B9txDZqr+ek/EYDNQ8XjZk1mmSIngXzdmCU4qIMAft8pM+TLyiNbbD04UXtFQmO
kFca4cgjj15EOaBCVvrF/z3kEUORhy8zc7TAVRvBUiGMVAetm+YEE6aZDppQIV47
xU7efSbpBQDR7JcAKd8h
=pJIK
-----END PGP SIGNATURE-----

--Apple-Mail=_DFAFAABE-A741-4002-B7C7-0EF235B4E55C--

From tnadeau@lucidvision.com  Wed Jan 22 06:18:53 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C949F1A00D9 for ; Wed, 22 Jan 2014 06:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level: 
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 naALHD0a50fr for ; Wed, 22 Jan 2014 06:18:51 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE5C1A00B6 for ; Wed, 22 Jan 2014 06:18:51 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CE9A726C2D88; Wed, 22 Jan 2014 09:18:50 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_445800BD-3AD9-4676-BA80-A104E952766C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243D46E9@AZ-FFEXMB04.global.avaya.com>
Date: Wed, 22 Jan 2014 09:18:50 -0500
Message-Id: <32B3803D-A8A3-4AC9-8114-A088D11811CE@lucidvision.com>
References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> <52DF9D02.6070306@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA243D46E9@AZ-FFEXMB04.global.avaya.com>
To: "Romascanu, Dan (Dan)" 
X-Mailer: Apple Mail (2.1827)
Cc: Farrel Adrian , "MIB Doctors \(E-mail\)" 
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 14:18:54 -0000

--Apple-Mail=_445800BD-3AD9-4676-BA80-A104E952766C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1E2C29CB-FDA2-4FBE-BDA7-069278AAAD97"


--Apple-Mail=_1E2C29CB-FDA2-4FBE-BDA7-069278AAAD97
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1255


On Jan 22, 2014:5:52 AM, at 5:52 AM, Romascanu, Dan (Dan) =
 wrote:

> Hi,
> =20
> As we seem to have agreed with the principle let me throw a few =
comments about the proposed text:
> =20
> "The OPS Area henceforth strongly discourages the pursuit of writable =
SNMP MIBs for configuration purposes by working groups except in cases =
of clear utility and overwhelming consensus to do so. In all other =
cases, we recommend the use of NETCONF/YANG IETF standards for =
configuration, specifically in new charters."
> =20
> -          We are preaching to the word to avoid using =91SNMP MIBs=92 =
so let us be consistent with ourselves J s/SNMP MIBs/SNMP MIB objects/
> -          An example of clear utility would be useful. I am thinking =
for example the case of MIB objects that enable/disable notifications. =
If these are the only writeable objects in a MIB module, I do not think =
we should recommend supporting NETCONF/YANG just for enabling/disabling =
notifications
> -          I am reluctant to define a new class of consensus here and =
I do not know what =91overwhelming consensus=92 means. Let us drop this.
> =20
> As we say =91The OPS Area =85=92 I believe that this statement needs =
to go through some consensus call on the OPS Area or opsawg mail list.
> =20
> I have no problem with posting this first on the MIB doctors wiki, but =
running it later as an IESG statement would send a stronger and more =
visible signal to all WGs in the IETF.

	I agree. The two-step approach likely gets the most impact.   =
Start with Ops Area/MIB Doctors and then IESG?

	--Tom



>  Regards,
> =20
> Dan
> =20
> =20
> From: Benoit Claise [mailto:bclaise@cisco.com]=20
> Sent: =E9=E5=ED =E3 22 =E9=F0=E5=E0=F8 2014 12:27
> To: adrian@olddog.co.uk; 'Bert Wijnen (IETF)'; 'Thomas Nadeau'; =
Romascanu, Dan (Dan)
> Cc: 'MIB Doctors (E-mail)'
> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
> =20
> Adrian, All,
>=20
> As expected and desired, this generated some good discussions (also in =
a different email thread between the MIB doctors)
>=20
> So we went=20
> - from "SNMPSet is dead", as a comment to make people react
> - to "SNMPSet is dead?"=20
> - to "we do not require writable MIB modules"
> - A statement such as "The OPS Area henceforth strongly discourages =
the pursuit of writable SNMP MIBs by working groups except in cases of =
clear utility and overwhelming consensus to do so. In all other cases, =
we recommend the use of tools such as Netconf/Netmod for configuration."
> - to "do not use writeable objects for configuration in MIB modules"
>=20
> We could go with an IESG statement, but I propose to make it easy to =
start with, with a statement on the MIB doctors page =
(http://www.ietf.org/iesg/directorate/mib-doctors.html)
> "The OPS Area henceforth strongly discourages the pursuit of writable =
SNMP MIBs for configuration purposes by working groups except in cases =
of clear utility and overwhelming consensus to do so. In all other =
cases, we recommend the use of NETCONF/YANG IETF standards for =
configuration, specifically in new charters."
> - I added "for configuration". SNMPSet could potentially be used for =
action.
> - I removed "such as" in "tools such as Netconf/Netmod for =
configuration." Not sure what you're referring to here Tom
> - I added "specifically in new charters." Right now, there are =
read-write MIB modules in EMAN. It would not be a sound idea to say now, =
specifically when documents went through LC: stop what you're doing, =
recharter to do YANG modules. What's key in EMAN is that an Information =
Model has been specified part of the framework.
>=20
> Feedback?
>=20
> Regards, Benoit
>=20
> (speaking as not a MIB Doctor)
> =20
> I like that very much, thanks for the words Tom.
> =20
> Benoit, do you think this is a big enough issue that we should make it =
an IESG
> statement?
> Or do you just want to run it through the OPSAWG in some way?
> =20
> A
> =20
> -----Original Message-----
> From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
> Sent: 21 January 2014 15:30
> To: Thomas Nadeau; Romascanu, Dan (Dan)
> Cc: MIB Doctors (E-mail); Farrel Adrian
> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
> =20
> sounds good to me
> =20
> Bert
> =20
> On 21/01/14 16:14, Thomas Nadeau wrote:
> =20
>     Agreed. Something like, "The OPS Area henceforth strongly =
discourages
> the pursuit of writable SNMP MIBs by working groups except in cases of =
clear
> utility and overwhelming consensus to do so. In all other cases, we =
recommend
> the use of tools such as Netconf/Netmod for configuration."
> =20
>     --Tom
> =20
> =20
> Hi Tom,
> =20
> This is exactly my point. I think that we should not only say 'do not =
do
> Sets
> using SNMP'. We should also say what to do instead.
> =20
> Regards,
> =20
> Dan
> =20
> =20
> -----Original Message-----
> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
> =20
> ....
> =20
>        I do agree that guidance needs to be issues to developers and
> especially IETF WGs on this matter.
> =20
>        --Tom
> =20
> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
> =20
> =20
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
> .
> =20
> =20


--Apple-Mail=_1E2C29CB-FDA2-4FBE-BDA7-069278AAAD97
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1255


On Jan 22, 2014:5:52 AM, at 5:52 AM, =
Romascanu, Dan (Dan) <dromasca@avaya.com> =
wrote:

Hi,
 
As we seem to have agreed =
with the principle let me throw a few comments about the proposed =
text:
 
"The =
OPS Area henceforth strongly discourages the pursuit of writable SNMP =
MIBs for configuration purposes by working groups except in cases of =
clear utility and overwhelming consensus to do so. In all other cases, =
we recommend the use of NETCONF/YANG IETF standards for configuration, =
specifically in new charters."
 
-          We are preaching to the word to =
avoid using =91SNMP MIBs=92 so let us be consistent with ourselves J s/SNMP MIBs/SNMP MIB =
objects/
-          An example of clear utility would =
be useful. I am thinking for example the case of MIB objects that =
enable/disable notifications. If these are the only writeable objects in =
a MIB module, I do not think we should recommend supporting NETCONF/YANG =
just for enabling/disabling notifications
-          I am reluctant to define a new =
class of consensus here and I do not know what =91overwhelming =
consensus=92 means. Let us drop this.
 
As we say =91The OPS Area =
=85=92 I believe that this statement needs to go through some consensus =
call on the OPS Area or opsawg mail list.
 
I have no problem with =
posting this first on the MIB doctors wiki, but running it later as an =
IESG statement would send a stronger and more visible signal to all WGs =
in the IETF.

	I agree. =
The two-step approach likely gets the most impact.   Start with Ops =
Area/MIB Doctors and then IESG?

	=
--Tom



 Regards,
 
Dan
 
 
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: =E9=E5=ED =E3 22 =E9=F0=E5=E0=F8 2014 =
12:27
To: adrian@olddog.co.uk; 'Bert Wijnen =
(IETF)'; 'Thomas Nadeau'; Romascanu, Dan (Dan)
Cc: 'MIB Doctors =
(E-mail)'
Subject: Re: [MIB-DOCTORS] Why is =
this MIB module read-write?
 
Adrian, All,

As expected and desired, this generated some =
good discussions (also in a different email thread between the MIB =
doctors)

So we went 
- from "SNMPSet is =
dead", as a comment to make people react
- to "SNMPSet is dead?" 
- to "we do not require =
writable MIB modules"
- A statement such as "The OPS Area henceforth =
strongly discourages the pursuit of writable SNMP MIBs by working groups =
except in cases of clear utility and overwhelming consensus to do so. In =
all other cases, we recommend the use of tools such as Netconf/Netmod =
for configuration."
- to "do not use writeable objects for =
configuration in =
MIB modules"

We could go with an IESG statement, but I propose to =
make it easy to start with, with a statement on the MIB doctors page (http://www.ietf.org/iesg/directorate/mib-doctors.html)
"The OPS Area henceforth =
strongly discourages the pursuit of writable SNMP MIBs for configuration =
purposes by working groups except in cases of clear utility and =
overwhelming consensus to do so. In all other cases, we recommend the =
use of NETCONF/YANG IETF standards for configuration, specifically in =
new charters."
- =
I added "for configuration". SNMPSet could potentially be used for =
action.
- I removed "such as" in "tools such as Netconf/Netmod for =
configuration." Not sure what you're referring to here Tom
- I added =
"specifically in new charters." Right now, there are read-write MIB =
modules in EMAN. It would not be a sound idea to say now, specifically =
when documents went through LC: stop what you're doing, recharter to do =
YANG modules. What's key in EMAN is that an Information Model has been =
specified part of the framework.

Feedback?

Regards, =
Benoit
(speaking as not a MIB =
Doctor)
 
I like that very much, =
thanks for the words Tom.
 
Benoit, do you think this =
is a big enough issue that we should make it an =
IESG
statement?
Or do you just want to run it through the OPSAWG in some =
way?
 
A
 
-----Original =
Message-----
From: Bert Wijnen (IETF) =
[mailto:bertietf@bwijnen.net]
Sent: 21 January 2014 15:30
To: Thomas Nadeau; Romascanu, Dan =
(Dan)
Cc: MIB Doctors (E-mail); Farrel =
Adrian
Subject: Re: [MIB-DOCTORS] =
Why is this MIB module read-write?
 
sounds good to =
me
 
Bert
 
On 21/01/14 16:14, Thomas =
Nadeau wrote:
 
    Agreed. Something like, "The OPS Area =
henceforth strongly discourages
the pursuit of writable SNMP MIBs by working groups =
except in cases of clear
utility and =
overwhelming consensus to do so. In all other cases, we =
recommend
the use of tools such as =
Netconf/Netmod for configuration."
 
    =
--Tom
 
 
Hi =
Tom,
 
This is exactly my point. I think that we should not =
only say 'do not =
do
Sets
using SNMP'. We should =
also say what to do instead.
 
Regards,
 
Dan
 
 
-----Original =
Message-----
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
 
....
 
       =
I do agree that guidance needs to be issues to developers =
and
especially IETF WGs on this =
matter.
 
       --Tom
 
 
 
 
 
 
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors
 
 
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors
.
 
 

=

--Apple-Mail=_1E2C29CB-FDA2-4FBE-BDA7-069278AAAD97--

--Apple-Mail=_445800BD-3AD9-4676-BA80-A104E952766C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS39NKAAoJEPcO+I7eiUJZzmAP+gIy8yDr/AmyjDaLV34UQPYb
FGXLzmb00p/4ULnHGA6NDrrQGRqEAHbcPVe9oWJC3sv7wa/WkTZ3GHiGB4wFuKqX
W/AgLK/6KEBK/SGZANOvDJqKcgBijhGkKUR6xXL4yn2mFlm/25aTp66GxleSjKMX
vlSrC8dtEJXOKqh4voTNSgDDywgAt2vP95KMJcuHhTTFf+/4lT61Bnhm2AJstOgv
94920JQFvNQXM5nWXWaRvunzsFbuVh2cXF1it6mjCMaZ92UmZMERvZg1OIMVgWhj
dYWwXEg169IQbwyhA0CtIz3UAubIB1YyxT65JEcIx8qJKKSqVkQo9bT3EZYwdDkj
hVBZBpGqgoRMcufQ6z7USlU3wYb7IJcEjQx1qmX5+ESWcvz6OInXmnl7KSmn7l1h
HSSqXw8T1yQK+di99ulpe8lG1BrKga959V/ceVDmr2dmxmZBn+r/unOvccAhW7Ny
Iyr1SuFX72M+PCKiszFDDGL0PDMcHO31TN+eUmFEeiTDjZrDdDdMrAyi/Ek14JkD
cZvhxHxSfR0FA+sx2x4aor1YcKXNF3Nlt7yEM7WAiEOQtd1WBk5NWL8NEr8u7A9/
ZgPr6Cb89MJ3eJGACslyOyLbQnzYJNRzJYZBDPxqv4MXmfo2t4BdlYhZGvFZ4f8n
e9TWEqrCMESKJabB9aj7
=h2Kf
-----END PGP SIGNATURE-----

--Apple-Mail=_445800BD-3AD9-4676-BA80-A104E952766C--

From adrian@olddog.co.uk  Wed Jan 22 08:42:56 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701621A035C for ; Wed, 22 Jan 2014 08:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.552
X-Spam-Level: 
X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 GRWV3hGTboRq for ; Wed, 22 Jan 2014 08:42:53 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id AC68F1A014B for ; Wed, 22 Jan 2014 08:42:52 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0MGgf9b011815; Wed, 22 Jan 2014 16:42:41 GMT
Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0MGgbZC011740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 16:42:39 GMT
From: "Adrian Farrel" 
To: "'Thomas Nadeau'" , "'Romascanu, Dan \(Dan\)'" 
References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> <52DF9D02.6070306@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA243D46E9@AZ-FFEXMB04.global.avaya.com> <32B3803D-A8A3-4AC9-8114-A088D11811CE@lucidvision.com>
In-Reply-To: <32B3803D-A8A3-4AC9-8114-A088D11811CE@lucidvision.com>
Date: Wed, 22 Jan 2014 16:42:39 -0000
Message-ID: <0e0701cf1790$f8c87550$ea595ff0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E08_01CF1790.F8D01670"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEwrXAyK+Ki1CwZFR7+hxZNRxmWogG0C+dEAt2mkkAAjOOq2wFR3747AW/TSmIB1Go8ewNFXgmVAb8aqZQB5Bs04wH1fzi6mzkuWXA=
Content-Language: en-gb
Cc: "'MIB Doctors \(E-mail\)'" 
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 16:42:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0E08_01CF1790.F8D01670
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Speaking as not-a-mib-doctor I am able to be a little cynical :-)
=20
Getting OPS Area consensus and getting MIB doctor consensus is =
essential.
=20
Posting on the MIB guidance wiki will have no impact on the IETF except =
in as
much as MIB Doctors will read it and apply it in their reviews/guidance. =
The
rest of the IETF (even the authors of MIB documents) will not read this =
page let
alone be influenced by it.
=20
An IESG statement or an RFC is the most powerful tool we have to make =
any
difference.
=20
But running all of these in sequence (with the intention of completing =
them all)
would be great.
=20
A
=20
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20
Sent: 22 January 2014 14:19
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; Farrel Adrian; Bert Wijnen (IETF); MIB Doctors =
(E-mail)
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
=20
=20
On Jan 22, 2014:5:52 AM, at 5:52 AM, Romascanu, Dan (Dan) =

wrote:



Hi,
=20
As we seem to have agreed with the principle let me throw a few comments =
about
the proposed text:
=20
"The OPS Area henceforth strongly discourages the pursuit of writable =
SNMP MIBs
for configuration purposes by working groups except in cases of clear =
utility
and overwhelming consensus to do so. In all other cases, we recommend =
the use of
NETCONF/YANG IETF standards for configuration, specifically in new =
charters."
=20
-          We are preaching to the word to avoid using =91SNMP MIBs=92 =
so let us be
consistent with ourselves J s/SNMP MIBs/SNMP MIB objects/
-          An example of clear utility would be useful. I am thinking =
for
example the case of MIB objects that enable/disable notifications. If =
these are
the only writeable objects in a MIB module, I do not think we should =
recommend
supporting NETCONF/YANG just for enabling/disabling notifications
-          I am reluctant to define a new class of consensus here and I =
do not
know what =91overwhelming consensus=92 means. Let us drop this.
=20
As we say =91The OPS Area =85=92 I believe that this statement needs to =
go through
some consensus call on the OPS Area or opsawg mail list.
=20
I have no problem with posting this first on the MIB doctors wiki, but =
running
it later as an IESG statement would send a stronger and more visible =
signal to
all WGs in the IETF.
=20
          I agree. The two-step approach likely gets the most impact.   =
Start
with Ops Area/MIB Doctors and then IESG?
=20
          --Tom
=20
=20



 Regards,
=20
Dan
=20
=20
From: Benoit Claise [  =
mailto:bclaise@cisco.com]=20
Sent: =E9=E5=ED =E3 22 =E9=F0=E5=E0=F8 2014 12:27
To:   adrian@olddog.co.uk; 'Bert Wijnen =
(IETF)';
'Thomas Nadeau'; Romascanu, Dan (Dan)
Cc: 'MIB Doctors (E-mail)'
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
=20
Adrian, All,

As expected and desired, this generated some good discussions (also in a
different email thread between the MIB doctors)

So we went=20
- from "SNMPSet is dead", as a comment to make people react
- to "SNMPSet is dead?"=20
- to "we do not require writable MIB modules"
- A statement such as "The OPS Area henceforth strongly discourages the =
pursuit
of writable SNMP MIBs by working groups except in cases of clear utility =
and
overwhelming consensus to do so. In all other cases, we recommend the =
use of
tools such as Netconf/Netmod for configuration."
- to "do not use writeable objects for configuration in MIB modules"

We could go with an IESG statement, but I propose to make it easy to =
start with,
with a statement on the MIB doctors page (

http://www.ietf.org/iesg/directorate/mib-doctors.html)
"The OPS Area henceforth strongly discourages the pursuit of writable =
SNMP MIBs
for configuration purposes by working groups except in cases of clear =
utility
and overwhelming consensus to do so. In all other cases, we recommend =
the use of
NETCONF/YANG IETF standards for configuration, specifically in new =
charters."
- I added "for configuration". SNMPSet could potentially be used for =
action.
- I removed "such as" in "tools such as Netconf/Netmod for =
configuration." Not
sure what you're referring to here Tom
- I added "specifically in new charters." Right now, there are =
read-write MIB
modules in EMAN. It would not be a sound idea to say now, specifically =
when
documents went through LC: stop what you're doing, recharter to do YANG =
modules.
What's key in EMAN is that an Information Model has been specified part =
of the
framework.

Feedback?

Regards, Benoit
(speaking as not a MIB Doctor)
=20
I like that very much, thanks for the words Tom.
=20
Benoit, do you think this is a big enough issue that we should make it =
an IESG
statement?
Or do you just want to run it through the OPSAWG in some way?
=20
A
=20
-----Original Message-----
From: Bert Wijnen (IETF) [ 
mailto:bertietf@bwijnen.net]
Sent: 21 January 2014 15:30
To: Thomas Nadeau; Romascanu, Dan (Dan)
Cc: MIB Doctors (E-mail); Farrel Adrian
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
=20
sounds good to me
=20
Bert
=20
On 21/01/14 16:14, Thomas Nadeau wrote:
=20
    Agreed. Something like, "The OPS Area henceforth strongly =
discourages
the pursuit of writable SNMP MIBs by working groups except in cases of =
clear
utility and overwhelming consensus to do so. In all other cases, we =
recommend
the use of tools such as Netconf/Netmod for configuration."
=20
    --Tom
=20
=20
Hi Tom,
=20
This is exactly my point. I think that we should not only say 'do not do
Sets
using SNMP'. We should also say what to do instead.
=20
Regards,
=20
Dan
=20
=20
-----Original Message-----
From: Thomas Nadeau [ 
mailto:tnadeau@lucidvision.com]
=20
....
=20
       I do agree that guidance needs to be issues to developers and
especially IETF WGs on this matter.
=20
       --Tom
=20
=20
=20
=20
=20
=20
_______________________________________________
MIB-DOCTORS mailing list
  MIB-DOCTORS@ietf.org
 
https://www.ietf.org/mailman/listinfo/mib-doctors
=20
=20
_______________________________________________
MIB-DOCTORS mailing list
  MIB-DOCTORS@ietf.org
 
https://www.ietf.org/mailman/listinfo/mib-doctors
.
=20
=20
=20

------=_NextPart_000_0E08_01CF1790.F8D01670
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable


Speaking as not-a-mib-doctor I =
am able to be a little cynical :-)
 
Getting OPS Area consensus and =
getting MIB doctor consensus is essential.
 
Posting on the MIB guidance =
wiki will have no impact on the IETF except in as much as MIB Doctors =
will read it and apply it in their reviews/guidance. The rest of the =
IETF (even the authors of MIB documents) will not read this page let =
alone be influenced by it.
 
An IESG statement or an RFC is =
the most powerful tool we have to make any =
difference.
 
But running all of these in =
sequence (with the intention of completing them all) would be =
great.
 
A
 
From: Thomas Nadeau =
[mailto:tnadeau@lucidvision.com] 
Sent: 22 January 2014 =
14:19
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; =
Farrel Adrian; Bert Wijnen (IETF); MIB Doctors =
(E-mail)
Subject: Re: [MIB-DOCTORS] Why is this MIB module =
read-write?
 
 
On Jan 22, 2014:5:52 =
AM, at 5:52 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> =
wrote:


Hi,
 
As =
we seem to have agreed with the principle let me throw a few comments =
about the proposed text:
 
"The OPS Area henceforth strongly =
discourages the pursuit of writable SNMP MIBs for configuration purposes =
by working groups except in cases of clear utility and overwhelming =
consensus to do so. In all other cases, we recommend the use of =
NETCONF/YANG IETF standards for configuration, specifically in new =
charters."
 
-    &nb=
sp;     We =
are preaching to the word to avoid using =91SNMP MIBs=92 so let us be =
consistent with ourselves J s/SNMP MIBs/SNMP MIB =
objects/
-    &nb=
sp;     An =
example of clear utility would be useful. I am thinking for example the =
case of MIB objects that enable/disable notifications. If these are the =
only writeable objects in a MIB module, I do not think we should =
recommend supporting NETCONF/YANG just for enabling/disabling =
notifications
-    &nb=
sp;     I =
am reluctant to define a new class of consensus here and I do not know =
what =91overwhelming consensus=92 means. Let us drop this.
 
As =
we say =91The OPS Area =85=92 I believe that this statement needs to go =
through some consensus call on the OPS Area or opsawg mail =
list.
 
I =
have no problem with posting this first on the MIB doctors wiki, but =
running it later as an IESG statement would send a stronger and more =
visible signal to all WGs in the IETF.
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
I agree. The two-step approach likely gets the most impact. =
  Start with Ops Area/MIB Doctors and then =
IESG?
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
--Tom
 
 


 Regards,
 
Dan
 
 
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: =E9=E5=ED =E3 22 =E9=F0=E5=E0=F8 2014 =
12:27
To: adrian@olddog.co.uk; 'Bert Wijnen =
(IETF)'; 'Thomas Nadeau'; Romascanu, Dan (Dan)
Cc: 'MIB Doctors =
(E-mail)'
Subject: Re: [MIB-DOCTORS] Why is this =
MIB module read-write?
<=
div>
 
Adrian, All,

As expected and =
desired, this generated some good discussions (also in a different email =
thread between the MIB doctors)

So we went 
- from "SNMPSet is =
dead", as a comment to make people react
- to "SNMPSet is =
dead?" 
- to =
"we do not require writable MIB modules"
- A statement such =
as "The OPS Area henceforth strongly discourages the pursuit of =
writable SNMP MIBs by working groups except in cases of clear utility =
and overwhelming consensus to do so. In all other cases, we recommend =
the use of tools such as Netconf/Netmod for configuration."
- to =
"do not use writeable objects for configuration in MIB =
modules"

We could go with an IESG statement, but I propose =
to make it easy to start with, with a statement on the MIB doctors page =
(http://www.ietf.org/iesg/directorate/mib-doctors.h=
tml)
"The OPS Area henceforth strongly =
discourages the pursuit of writable SNMP MIBs for configuration purposes =
by working groups except in cases of clear utility and overwhelming =
consensus to do so. In all other cases, we recommend the use of =
NETCONF/YANG IETF standards for configuration, specifically in new =
charters."
- I added "for =
configuration". SNMPSet could potentially be used for action.
- =
I removed "such as" in "tools such as Netconf/Netmod for =
configuration." Not sure what you're referring to here Tom
- I =
added "specifically in new charters." Right now, there are =
read-write MIB modules in EMAN. It would not be a sound idea to say now, =
specifically when documents went through LC: stop what you're doing, =
recharter to do YANG modules. What's key in EMAN is that an Information =
Model has been specified part of the =
framework.

Feedback?

Regards, =
Benoit
(speaking as not a MIB =
Doctor)
 
I like that very much, =
thanks for the words Tom.
 
Benoit, do you think =
this is a big enough issue that we should make it an =
IESG
statement?
=
Or do you just want =
to run it through the OPSAWG in some =
way?
 
A
 
-----Original =
Message-----
From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=

Sent: 21 January 2014 =
15:30
To: Thomas Nadeau; Romascanu, Dan =
(Dan)
Cc: MIB Doctors (E-mail); Farrel =
Adrian
Subject: Re: [MIB-DOCTORS] Why is this =
MIB module read-write?
 
sounds good to =
me
 
Bert
 
On 21/01/14 16:14, =
Thomas Nadeau wrote:
 
    =
Agreed. Something like, "The OPS Area henceforth strongly =
discourages
the pursuit of writable SNMP MIBs by =
working groups except in cases of =
clear
utility and overwhelming consensus to =
do so. In all other cases, we =
recommend
the use of tools such as =
Netconf/Netmod for =
configuration."
 
    =
--Tom
 
 
Hi =
Tom,
 
This is exactly my =
point. I think that we should not only say 'do not =
do
Sets
using SNMP'. We should also say what =
to do instead.
 
Regards,
 
Dan
 
 
-----Original =
Message-----
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
 
....
 
       I =
do agree that guidance needs to be issues to developers =
and
especially IETF WGs on this =
matter.
 
       =
--Tom
 
 
 
 
 
 
_______________________________________=
________
MIB-DOCTORS mailing =
list
MIB-DOCTORS@ietf.org<=
/pre>
https://www.ietf.org/mailman/listinfo/mib-doctors<=
/span>
 
 
_______________________________________=
________
MIB-DOCTORS mailing =
list
MIB-DOCTORS@ietf.org<=
/pre>
https://www.ietf.org/mailman/listinfo/mib-doctors<=
/span>
.
 
 
<=
/div>
 

------=_NextPart_000_0E08_01CF1790.F8D01670--


From bclaise@cisco.com  Wed Jan 22 09:26:00 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631BA1A011B for ; Wed, 22 Jan 2014 09:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 yTBVQH52BHb7 for ; Wed, 22 Jan 2014 09:25:56 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id BB6731A00E4 for ; Wed, 22 Jan 2014 09:25:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=72461; q=dns/txt; s=iport; t=1390411553; x=1391621153; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=4s6gHwdFXmq83zyb+T32KxFBamcBQQzEVwszFbYWxuE=; b=bq1H4JEWY9mK0t2Y2/eMkf0xKyd5bVlFZvkm7Ru/pzWpxKZIKfn8hRc/ dvIP8D33U3zUErfej/fncFJymGPyUxBuzUElKvkM8xw+/keTcH2lN0ilY KqAwzGH44H3K8q3Nlf+eFRDYdA1ZEsTnmd2Yz64Ya2ta53wqkHzwfM6BM k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgLAK7+31KQ/khR/2dsb2JhbABbgkhEOLUWhx+BFhZ0giUBAQEDAQEBASpBCgEFBwQJAhEEAQEBCRYBAQYHCQMCAQIBFAEfCQgGAQwBBAECAQEFh3QIDYpguBgXjhoQAgFPBgEGhDIEmCKGR4tRgy47
X-IronPort-AV: E=Sophos;i="4.95,701,1384300800"; d="scan'208,217";a="4024554"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 17:25:52 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0MHPp1G026362; Wed, 22 Jan 2014 17:25:51 GMT
Message-ID: <52DFFF1F.1060904@cisco.com>
Date: Wed, 22 Jan 2014 18:25:51 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, "'Thomas Nadeau'" , "'Romascanu, Dan (Dan)'" 
References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> <52DF9D02.6070306@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA243D46E9@AZ-FFEXMB04.global.avaya.com> <32B3803D-A8A3-4AC9-8114-A088D11811CE@lucidvision.com> <0e0701cf1790$f8c87550$ea595ff0$@olddog.co.uk>
In-Reply-To: <0e0701cf1790$f8c87550$ea595ff0$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------030902090301000609020300"
Cc: "'MIB Doctors \(E-mail\)'" 
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 17:26:00 -0000

This is a multi-part message in MIME format.
--------------030902090301000609020300
Content-Type: text/plain; charset=windows-1255; format=flowed
Content-Transfer-Encoding: 8bit


> Speaking as not-a-mib-doctor I am able to be a little cynical :-)
>
> Getting OPS Area consensus and getting MIB doctor consensus is essential.
>
> Posting on the MIB guidance wiki will have no impact on the IETF 
> except in as much as MIB Doctors will read it and apply it in their 
> reviews/guidance. The rest of the IETF (even the authors of MIB 
> documents) will not read this page let alone be influenced by it.
>
> An IESG statement or an RFC is the most powerful tool we have to make 
> any difference.
>
Yes, I slowly arrive to the conclusion that an IESG statement is 
actually the right thing to do.

B.
>
> But running all of these in sequence (with the intention of completing 
> them all) would be great.
>
> A
>
> *From:*Thomas Nadeau [mailto:tnadeau@lucidvision.com]
> *Sent:* 22 January 2014 14:19
> *To:* Romascanu, Dan (Dan)
> *Cc:* Benoit Claise; Farrel Adrian; Bert Wijnen (IETF); MIB Doctors 
> (E-mail)
> *Subject:* Re: [MIB-DOCTORS] Why is this MIB module read-write?
>
> On Jan 22, 2014:5:52 AM, at 5:52 AM, Romascanu, Dan (Dan) 
> > wrote:
>
>
>
> Hi,
>
> As we seem to have agreed with the principle let me throw a few 
> comments about the proposed text:
>
> "The OPS Area henceforth strongly discourages the pursuit of writable 
> SNMP MIBs for configuration purposes by working groups except in cases 
> of clear utility and overwhelming consensus to do so. In all other 
> cases, we recommend the use of NETCONF/YANG IETF standards for 
> configuration, specifically in new charters."
>
> -We are preaching to the word to avoid using ‘SNMP MIBs’ so let us be 
> consistent with ourselvesJs/SNMP MIBs/SNMP MIB objects/
>
> -An example of clear utility would be useful. I am thinking for 
> example the case of MIB objects that enable/disable notifications. If 
> these are the only writeable objects in a MIB module, I do not think 
> we should recommend supporting NETCONF/YANG just for 
> enabling/disabling notifications
>
> -I am reluctant to define a new class of consensus here and I do not 
> know what ‘overwhelming consensus’ means. Let us drop this.
>
> As we say ‘The OPS Area …’ I believe that this statement needs to go 
> through some consensus call on the OPS Area or opsawg mail list.
>
> I have no problem with posting this first on the MIB doctors wiki, but 
> running it later as an IESG statement would send a stronger and more 
> visible signal to all WGs in the IETF.
>
> I agree. The two-step approach likely gets the most impact.   Start 
> with Ops Area/MIB Doctors and then IESG?
>
> --Tom
>
>
>
>  Regards,
>
> Dan
>
> *From:*Benoit Claise [mailto:bclaise@cisco.com]
> *Sent:*éåíã22éðåàø2014 12:27
> *To:*adrian@olddog.co.uk ; 'Bert Wijnen 
> (IETF)'; 'Thomas Nadeau'; Romascanu, Dan (Dan)
> *Cc:*'MIB Doctors (E-mail)'
> *Subject:*Re: [MIB-DOCTORS] Why is this MIB module read-write?
>
> Adrian, All,
>
> As expected and desired, this generated some good discussions (also in 
> a different email thread between the MIB doctors)
>
> So we went
> - from "SNMPSet is dead", as a comment to make people react
> - to "SNMPSet is dead?"
> - to "we do not require writable MIB modules"
> - A statement such as "The OPS Area henceforth strongly discourages 
> the pursuit of writable SNMP MIBs by working groups except in cases of 
> clear utility and overwhelming consensus to do so. In all other cases, 
> we recommend the use of tools such as Netconf/Netmod for configuration."
> - to "do not use writeable objects_for configuration_in MIB modules"
>
> We could go with an IESG statement, but I propose to make it easy to 
> start with, with a statement on the MIB doctors page 
> (http://www.ietf.org/iesg/directorate/mib-doctors.html)
>
> "The OPS Area henceforth strongly discourages the pursuit of writable 
> SNMP MIBs for configuration purposes by working groups except in cases 
> of clear utility and overwhelming consensus to do so. In all other 
> cases, we recommend the use of NETCONF/YANG IETF standards for 
> configuration, specifically in new charters."
>
> - I added "for configuration". SNMPSet could potentially be used for 
> action.
> - I removed "such as" in "tools such as Netconf/Netmod for 
> configuration." Not sure what you're referring to here Tom
> - I added "specifically in new charters." Right now, there are 
> read-write MIB modules in EMAN. It would not be a sound idea to say 
> now, specifically when documents went through LC: stop what you're 
> doing, recharter to do YANG modules. What's key in EMAN is that an 
> Information Model has been specified part of the framework.
>
> Feedback?
>
> Regards, Benoit
>
>     (speaking as not a MIB Doctor)
>
>       
>
>     I like that very much, thanks for the words Tom.
>
>       
>
>     Benoit, do you think this is a big enough issue that we should make it an IESG
>
>     statement?
>
>     Or do you just want to run it through the OPSAWG in some way?
>
>       
>
>     A
>
>       
>
>         -----Original Message-----
>
>         From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
>
>         Sent: 21 January 2014 15:30
>
>         To: Thomas Nadeau; Romascanu, Dan (Dan)
>
>         Cc: MIB Doctors (E-mail); Farrel Adrian
>
>         Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
>
>           
>
>         sounds good to me
>
>           
>
>         Bert
>
>           
>
>         On 21/01/14 16:14, Thomas Nadeau wrote:
>
>               
>
>                  Agreed. Something like, "The OPS Area henceforth strongly discourages
>
>         the pursuit of writable SNMP MIBs by working groups except in cases of clear
>
>         utility and overwhelming consensus to do so. In all other cases, we recommend
>
>         the use of tools such as Netconf/Netmod for configuration."
>
>               
>
>                  --Tom
>
>               
>
>               
>
>                 Hi Tom,
>
>                   
>
>                 This is exactly my point. I think that we should not only say 'do not do
>
>     Sets
>
>         using SNMP'. We should also say what to do instead.
>
>                   
>
>                 Regards,
>
>                   
>
>                 Dan
>
>                   
>
>                   
>
>                     -----Original Message-----
>
>                     From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
>
>                   
>
>                 ....
>
>                   
>
>                             I do agree that guidance needs to be issues to developers and
>
>                     especially IETF WGs on this matter.
>
>                       
>
>                             --Tom
>
>                       
>
>                   
>
>                   
>
>               
>
>               
>
>               
>
>             _______________________________________________
>
>             MIB-DOCTORS mailing list
>
>             MIB-DOCTORS@ietf.org  
>
>             https://www.ietf.org/mailman/listinfo/mib-doctors
>
>               
>
>       
>
>     _______________________________________________
>
>     MIB-DOCTORS mailing list
>
>     MIB-DOCTORS@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/mib-doctors
>
>     .
>
>       
>


--------------030902090301000609020300
Content-Type: text/html; charset=windows-1255
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

      
      
      
      
      
      
      
      

        
Speaking as not-a-mib-doctor
            I am able to be a little cynical :-)

        
 

        
Getting OPS Area consensus
            and getting MIB doctor consensus is essential.

        
 

        
Posting on the MIB guidance
            wiki will have no impact on the IETF except in as much as
            MIB Doctors will read it and apply it in their
            reviews/guidance. The rest of the IETF (even the authors of
            MIB documents) will not read this page let alone be
            influenced by it.

        
 

        
An IESG statement or an RFC
            is the most powerful tool we have to make any difference.

      

    

    Yes, I slowly arrive to the conclusion that an IESG statement is
    actually the right thing to do.

    

    B.

    

      

        

        
 

        
But running all of these in
            sequence (with the intention of completing them all) would
            be great.

        
 

        
A

        
 

        

          

            

              
From:
                  Thomas Nadeau [mailto:tnadeau@lucidvision.com] 

                  Sent: 22 January 2014 14:19

                  To: Romascanu, Dan (Dan)

                  Cc: Benoit Claise; Farrel Adrian; Bert Wijnen
                  (IETF); MIB Doctors (E-mail)

                  Subject: Re: [MIB-DOCTORS] Why is this MIB
                  module read-write?

            

          

          
 

          
 

          

            

              
On Jan 22, 2014:5:52 AM, at 5:52 AM,
                  Romascanu, Dan (Dan) <dromasca@avaya.com>
                  wrote:

            

            


                

                

            

              

                
Hi,

              

              

                
 

              

              

                
As we seem to have agreed with the
                    principle let me throw a few comments about the
                    proposed text:

              

              

                
 

              

              

                
"The
                    OPS Area henceforth strongly discourages the pursuit
                    of writable SNMP MIBs for configuration purposes by
                    working groups except in cases of clear utility and
                    overwhelming consensus to do so. In all other cases,
                    we recommend the use of NETCONF/YANG IETF standards
                    for configuration, specifically in new charters."

              

              

                
 

              

              

                
-          We are preaching to the word to avoid
                    using ‘SNMP MIBs’ so let us be consistent with
                    ourselves J s/SNMP MIBs/SNMP MIB objects/

              

              

                
-          An example of clear utility would be
                    useful. I am thinking for example the case of MIB
                    objects that enable/disable notifications. If these
                    are the only writeable objects in a MIB module, I do
                    not think we should recommend supporting
                    NETCONF/YANG just for enabling/disabling
                    notifications

              

              

                
-          I am reluctant to define a new class of
                    consensus here and I do not know what ‘overwhelming
                    consensus’ means. Let us drop this.

              

              

                
 

              

              

                
As we say ‘The OPS Area …’ I believe
                    that this statement needs to go through some
                    consensus call on the OPS Area or opsawg mail list.

              

              

                
 

              

              

                
I have no problem with posting this
                    first on the MIB doctors wiki, but running it later
                    as an IESG statement would send a stronger and more
                    visible signal to all WGs in the IETF.

              

            

            

              
 

            

            
          I agree. The two-step approach likely gets
                the most impact.   Start with Ops Area/MIB Doctors and
                then IESG?

          

          

            
 

          

          

            
          --Tom

          

          

            
 

          

          

            
 

          

          

            


                

                

            

              

                
 Regards,

              

              

                
 

              

              

                
Dan

              

              

                
 

              

              

                
 

              

              

                

                  

                    

                      
From: Benoit Claise [mailto:bclaise@cisco.com] 

                          Sent: éåí ã 22 éðåàø 2014 12:27

                          To: adrian@olddog.co.uk;
                          'Bert Wijnen (IETF)'; 'Thomas Nadeau';
                          Romascanu, Dan (Dan)

                          Cc: 'MIB
                          Doctors (E-mail)'

                          Subject: Re:
                          [MIB-DOCTORS] Why is this MIB module
                          read-write?

                    

                  

                

                

                  
 

                

                

                  

                    
Adrian, All,

                        

                        As expected and desired, this generated some
                        good discussions (also in a different email
                        thread between the MIB doctors)

                        

                        So we went 

                        - from "SNMPSet is dead", as a comment to make
                        people react

                        - to "SNMPSet is dead?" 

                        - to "we do not require writable MIB modules"

                        - A statement such as "The OPS Area henceforth
                        strongly discourages the pursuit of writable
                        SNMP MIBs by working groups except in cases of
                        clear utility and overwhelming consensus to do
                        so. In all other cases, we recommend the use of
                        tools such as Netconf/Netmod for configuration."

                        - to "do not use writeable objects for
                          configuration in MIB
                        modules"

                        

                        We could go with an IESG statement, but I
                        propose to make it easy to start with, with a
                        statement on the MIB doctors page (http://www.ietf.org/iesg/directorate/mib-doctors.html)

                  

                  

                    
"The OPS Area henceforth strongly
                        discourages the pursuit of writable SNMP MIBs
                        for configuration purposes by working groups
                        except in cases of clear utility and
                        overwhelming consensus to do so. In all other
                        cases, we recommend the use of NETCONF/YANG IETF
                        standards for configuration, specifically in new
                        charters."

                  

                  
- I
                      added "for configuration". SNMPSet could
                      potentially be used for action.

                      - I removed "such as" in "tools such as
                      Netconf/Netmod for configuration." Not sure what
                      you're referring to here Tom

                      - I added "specifically in new charters." Right
                      now, there are read-write MIB modules in EMAN. It
                      would not be a sound idea to say now, specifically
                      when documents went through LC: stop what you're
                      doing, recharter to do YANG modules. What's key in
                      EMAN is that an Information Model has been
                      specified part of the framework.

                      

                      Feedback?

                      

                      Regards, Benoit

                

                

                  
(speaking as not a MIB Doctor)

                  
 

                  
I like that very much, thanks for the words Tom.

                  
 

                  
Benoit, do you think this is a big enough issue that we should make it an IESG

                  
statement?

                  
Or do you just want to run it through the OPSAWG in some way?

                  
 

                  
A

                  
 

                  

                    
-----Original Message-----

                    
From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]

                    
Sent: 21 January 2014 15:30

                    
To: Thomas Nadeau; Romascanu, Dan (Dan)

                    
Cc: MIB Doctors (E-mail); Farrel Adrian

                    
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

                    
 

                    
sounds good to me

                    
 

                    
Bert

                    
 

                    
On 21/01/14 16:14, Thomas Nadeau wrote:

                    

                      
 

                      
    Agreed. Something like, "The OPS Area henceforth strongly discourages

                    

                    
the pursuit of writable SNMP MIBs by working groups except in cases of clear

                    
utility and overwhelming consensus to do so. In all other cases, we recommend

                    
the use of tools such as Netconf/Netmod for configuration."

                    

                      
 

                      
    --Tom

                      
 

                      
 

                      

                        
Hi Tom,

                        
 

                        
This is exactly my point. I think that we should not only say 'do not do

                      

                    

                  

                  
Sets

                  

                    
using SNMP'. We should also say what to do instead.

                    

                      

                        
 

                        
Regards,

                        
 

                        
Dan

                        
 

                        
 

                        

                          
-----Original Message-----

                          
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]

                        

                        
 

                        
....

                        
 

                        

                          
       I do agree that guidance needs to be issues to developers and

                          
especially IETF WGs on this matter.

                          
 

                          
       --Tom

                          
 

                        

                        
 

                        
 

                      

                      
 

                      
 

                      
 

                      
_______________________________________________

                      
MIB-DOCTORS mailing list

                      
MIB-DOCTORS@ietf.org

                      
https://www.ietf.org/mailman/listinfo/mib-doctors

                      
 

                    

                  

                  
 

                  
_______________________________________________

                  
MIB-DOCTORS mailing list

                  
MIB-DOCTORS@ietf.org

                  
https://www.ietf.org/mailman/listinfo/mib-doctors

                  
.

                  
 

                

                

                  
 

                

              

            

          

          
 

        

      

    

    

  


--------------030902090301000609020300--

From bclaise@cisco.com  Wed Jan 22 10:50:58 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9C21A0159 for ; Wed, 22 Jan 2014 10:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Wi9xiAA53nh6 for ; Wed, 22 Jan 2014 10:50:56 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 428FC1A014B for ; Wed, 22 Jan 2014 10:50:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27829; q=dns/txt; s=iport; t=1390416655; x=1391626255; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=v1JXfzTNUDcH4VgoDI0ffK0yAR6IYttNBSFd0rE+KD0=; b=hued8sPnN6AclvmCF4rImXzlvCKuv1Rq9w4oq81f9+NtzZ0CcTOs5a3v OJDkraaMCtieJhntSclZ+kvhbocE2GBH9OOqW3mNxYWhEWSHG97iMUUvz JQu0TDlKwfsWySyX9Arg5zVAbwtPyTZk7PH+ZjiLyZeuWwPTrnOWEpMne I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcLAJMS4FKQ/khM/2dsb2JhbABbgkhEOLUUhx+BFhZ0giUBAQEEAQEBKkEKAQwECQIRBAEBAQkWAQEGBwkDAgECARUfCQgGAQwBBQIBAQWHfA2LCbgdF44aEAIBTwYBBoQyBJgihkeLUYMuOw
X-IronPort-AV: E=Sophos;i="4.95,701,1384300800"; d="scan'208,217";a="4027603"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 18:50:53 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0MIorin016277; Wed, 22 Jan 2014 18:50:53 GMT
Message-ID: <52E0130D.4040204@cisco.com>
Date: Wed, 22 Jan 2014 19:50:53 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" , "adrian@olddog.co.uk" , "'Bert Wijnen (IETF)'" , "'Thomas Nadeau'" 
References: <52DD5FFC.8070103@cisco.com> <20140121094726.GB47210@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA243D33C0@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA243D3C0F@AZ-FFEXMB04.global.avaya.com> <556BB556-669F-4EF5-B8B0-4F1CD7E45BD0@lucidvision.com> <52DE928D.1090909@bwijnen.net> <0b2301cf16ce$bad3a3e0$307aeba0$@olddog.co.uk> <52DF9D02.6070306@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA243D46E9@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243D46E9@AZ-FFEXMB04.global.avaya.com>
Content-Type: multipart/alternative; boundary="------------060201070403060501060103"
Cc: "'MIB Doctors \(E-mail\)'" 
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 18:50:58 -0000

This is a multi-part message in MIME format.
--------------060201070403060501060103
Content-Type: text/plain; charset=windows-1255; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dan,

All your comments make sense.
Let's work on the proposed text.

Regards, Benoit
>
> Hi,
>
> As we seem to have agreed with the principle let me throw a few 
> comments about the proposed text:
>
> "The OPS Area henceforth strongly discourages the pursuit of writable 
> SNMP MIBs for configuration purposes by working groups except in cases 
> of clear utility and overwhelming consensus to do so. In all other 
> cases, we recommend the use of NETCONF/YANG IETF standards for 
> configuration, specifically in new charters."
>
> -We are preaching to the word to avoid using ‘SNMP MIBs’ so let us be 
> consistent with ourselves Js/SNMP MIBs/SNMP MIB objects/
>
> -An example of clear utility would be useful. I am thinking for 
> example the case of MIB objects that enable/disable notifications. If 
> these are the only writeable objects in a MIB module, I do not think 
> we should recommend supporting NETCONF/YANG just for 
> enabling/disabling notifications
>
> -I am reluctant to define a new class of consensus here and I do not 
> know what ‘overwhelming consensus’ means. Let us drop this.
>
> As we say ‘The OPS Area …’ I believe that this statement needs to go 
> through some consensus call on the OPS Area or opsawg mail list.
>
> I have no problem with posting this first on the MIB doctors wiki, but 
> running it later as an IESG statement would send a stronger and more 
> visible signal to all WGs in the IETF.
>
> Regards,
>
> Dan
>
> *From:*Benoit Claise [mailto:bclaise@cisco.com]
> *Sent:* éåíã22 éðåàø2014 12:27
> *To:* adrian@olddog.co.uk; 'Bert Wijnen (IETF)'; 'Thomas Nadeau'; 
> Romascanu, Dan (Dan)
> *Cc:* 'MIB Doctors (E-mail)'
> *Subject:* Re: [MIB-DOCTORS] Why is this MIB module read-write?
>
> Adrian, All,
>
> As expected and desired, this generated some good discussions (also in 
> a different email thread between the MIB doctors)
>
> So we went
> - from "SNMPSet is dead", as a comment to make people react
> - to "SNMPSet is dead?"
> - to "we do not require writable MIB modules"
> - A statement such as "The OPS Area henceforth strongly discourages 
> the pursuit of writable SNMP MIBs by working groups except in cases of 
> clear utility and overwhelming consensus to do so. In all other cases, 
> we recommend the use of tools such as Netconf/Netmod for configuration."
> - to "do not use writeable objects _for configuration_ in MIB modules"
>
> We could go with an IESG statement, but I propose to make it easy to 
> start with, with a statement on the MIB doctors page 
> (http://www.ietf.org/iesg/directorate/mib-doctors.html)
>
> "The OPS Area henceforth strongly discourages the pursuit of writable 
> SNMP MIBs for configuration purposes by working groups except in cases 
> of clear utility and overwhelming consensus to do so. In all other 
> cases, we recommend the use of NETCONF/YANG IETF standards for 
> configuration, specifically in new charters."
>
> - I added "for configuration". SNMPSet could potentially be used for 
> action.
> - I removed "such as" in "tools such as Netconf/Netmod for 
> configuration." Not sure what you're referring to here Tom
> - I added "specifically in new charters." Right now, there are 
> read-write MIB modules in EMAN. It would not be a sound idea to say 
> now, specifically when documents went through LC: stop what you're 
> doing, recharter to do YANG modules. What's key in EMAN is that an 
> Information Model has been specified part of the framework.
>
> Feedback?
>
> Regards, Benoit
>
>     (speaking as not a MIB Doctor)
>
>       
>
>     I like that very much, thanks for the words Tom.
>
>       
>
>     Benoit, do you think this is a big enough issue that we should make it an IESG
>
>     statement?
>
>     Or do you just want to run it through the OPSAWG in some way?
>
>       
>
>     A
>
>       
>
>         -----Original Message-----
>
>         From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
>
>         Sent: 21 January 2014 15:30
>
>         To: Thomas Nadeau; Romascanu, Dan (Dan)
>
>         Cc: MIB Doctors (E-mail); Farrel Adrian
>
>         Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
>
>           
>
>         sounds good to me
>
>           
>
>         Bert
>
>           
>
>         On 21/01/14 16:14, Thomas Nadeau wrote:
>
>               
>
>                  Agreed. Something like, "The OPS Area henceforth strongly discourages
>
>         the pursuit of writable SNMP MIBs by working groups except in cases of clear
>
>         utility and overwhelming consensus to do so. In all other cases, we recommend
>
>         the use of tools such as Netconf/Netmod for configuration."
>
>               
>
>                  --Tom
>
>               
>
>               
>
>                 Hi Tom,
>
>                   
>
>                 This is exactly my point. I think that we should not only say 'do not do
>
>     Sets
>
>         using SNMP'. We should also say what to do instead.
>
>                   
>
>                 Regards,
>
>                   
>
>                 Dan
>
>                   
>
>                   
>
>                     -----Original Message-----
>
>                     From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
>
>                   
>
>                 ....
>
>                   
>
>                             I do agree that guidance needs to be issues to developers and
>
>                     especially IETF WGs on this matter.
>
>                       
>
>                             --Tom
>
>                       
>
>                   
>
>                   
>
>               
>
>               
>
>               
>
>             _______________________________________________
>
>             MIB-DOCTORS mailing list
>
>             MIB-DOCTORS@ietf.org  
>
>             https://www.ietf.org/mailman/listinfo/mib-doctors
>
>               
>
>       
>
>     _______________________________________________
>
>     MIB-DOCTORS mailing list
>
>     MIB-DOCTORS@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/mib-doctors
>
>     .
>
>       
>


--------------060201070403060501060103
Content-Type: text/html; charset=windows-1255
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dan, 

      

      All your comments make sense.

      Let's work on the proposed text.

      

      Regards, Benoit

    

    

      
      
      
      

        
Hi,

        
 

        
As
            we seem to have agreed with the principle let me throw a few
            comments about the proposed text:
            

        
 

        
"The OPS Area henceforth strongly
          discourages the pursuit of writable SNMP MIBs for
          configuration purposes by working groups except in cases of
          clear utility and overwhelming consensus to do so. In all
          other cases, we recommend the use of NETCONF/YANG IETF
          standards for configuration, specifically in new charters."

        
 

        
-         
              We
            are preaching to the word to avoid using ‘SNMP MIBs’ so let
            us be consistent with ourselves
          J
            s/SNMP MIBs/SNMP MIB objects/

        
-         
              An
            example of clear utility would be useful. I am thinking for
            example the case of MIB objects that enable/disable
            notifications. If these are the only writeable objects in a
            MIB module, I do not think we should recommend supporting
            NETCONF/YANG just for enabling/disabling notifications

        
-         
              I
            am reluctant to define a new class of consensus here and I
            do not know what ‘overwhelming consensus’ means. Let us drop
            this.
            

        
 

        
As
            we say ‘The OPS Area …’ I believe that this statement needs
            to go through some consensus call on the OPS Area or opsawg
            mail list.

        
 

        
I
            have no problem with posting this first on the MIB doctors
            wiki, but running it later as an IESG statement would send a
            stronger and more visible signal to all WGs in the IETF. 

        
 

        
Regards,

        
 

        
Dan

        
 

        
 

        

          

            

              
From:
                  Benoit Claise [mailto:bclaise@cisco.com]
                  

                  Sent: éåí ã 22 éðåàø 2014 12:27

                  To: adrian@olddog.co.uk; 'Bert Wijnen (IETF)';
                  'Thomas Nadeau'; Romascanu, Dan (Dan)

                  Cc: 'MIB Doctors (E-mail)'

                  Subject: Re: [MIB-DOCTORS] Why is this MIB
                  module read-write?

            

          

          
 

          

            
Adrian, All,

              

              As expected and desired, this generated some good
              discussions (also in a different email thread between the
              MIB doctors)

              

              So we went 

              - from "SNMPSet is dead", as a comment to make people
              react

              - to "SNMPSet is dead?" 

              - to "we do not require writable MIB modules"

              - A statement such as "The OPS Area henceforth strongly
              discourages the pursuit of writable SNMP MIBs by working
              groups except in cases of clear utility and overwhelming
              consensus to do so. In all other cases, we recommend the
              use of tools such as Netconf/Netmod for configuration."

              - to "do not use writeable objects for configuration
              in MIB modules"

              

              We could go with an IESG statement, but I propose to make
              it easy to start with, with a statement on the MIB doctors
              page (http://www.ietf.org/iesg/directorate/mib-doctors.html)

            
"The OPS Area henceforth strongly
              discourages the pursuit of writable SNMP MIBs for
              configuration purposes by working groups except in cases
              of clear utility and overwhelming consensus to do so. In
              all other cases, we recommend the use of NETCONF/YANG IETF
              standards for configuration, specifically in new
              charters."

            
- I added
              "for configuration". SNMPSet could potentially be used for
              action.

              - I removed "such as" in "tools such as Netconf/Netmod for
              configuration." Not sure what you're referring to here Tom

              - I added "specifically in new charters." Right now, there
              are read-write MIB modules in EMAN. It would not be a
              sound idea to say now, specifically when documents went
              through LC: stop what you're doing, recharter to do YANG
              modules. What's key in EMAN is that an Information Model
              has been specified part of the framework.

              

              Feedback?

              

              Regards, Benoit

          

          

            
(speaking as not a MIB Doctor)

            
 

            
I like that very much, thanks for the words Tom.

            
 

            
Benoit, do you think this is a big enough issue that we should make it an IESG

            
statement?

            
Or do you just want to run it through the OPSAWG in some way?

            
 

            
A

            
 

            

              
-----Original Message-----

              
From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]

              
Sent: 21 January 2014 15:30

              
To: Thomas Nadeau; Romascanu, Dan (Dan)

              
Cc: MIB Doctors (E-mail); Farrel Adrian

              
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

              
 

              
sounds good to me

              
 

              
Bert

              
 

              
On 21/01/14 16:14, Thomas Nadeau wrote:

              

                
 

                
    Agreed. Something like, "The OPS Area henceforth strongly discourages

              

              
the pursuit of writable SNMP MIBs by working groups except in cases of clear

              
utility and overwhelming consensus to do so. In all other cases, we recommend

              
the use of tools such as Netconf/Netmod for configuration."

              

                
 

                
    --Tom

                
 

                
 

                

                  
Hi Tom,

                  
 

                  
This is exactly my point. I think that we should not only say 'do not do

                

              

            

            
Sets

            

              
using SNMP'. We should also say what to do instead.

              

                

                  
 

                  
Regards,

                  
 

                  
Dan

                  
 

                  
 

                  

                    
-----Original Message-----

                    
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]

                  

                  
 

                  
....

                  
 

                  

                    
       I do agree that guidance needs to be issues to developers and

                    
especially IETF WGs on this matter.

                    
 

                    
       --Tom

                    
 

                  

                  
 

                  
 

                

                
 

                
 

                
 

                
_______________________________________________

                
MIB-DOCTORS mailing list

                
MIB-DOCTORS@ietf.org

                
https://www.ietf.org/mailman/listinfo/mib-doctors

                
 

              

            

            
 

            
_______________________________________________

            
MIB-DOCTORS mailing list

            
MIB-DOCTORS@ietf.org

            
https://www.ietf.org/mailman/listinfo/mib-doctors

            
.

            
 

          

          
 

        

      

    

    

  


--------------060201070403060501060103--

From tnadeau@lucidvision.com  Thu Jan 23 14:39:19 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F2C1A0462; Thu, 23 Jan 2014 14:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.433
X-Spam-Level: *
X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FILL_THIS_FORM=0.001, FILL_THIS_FORM_FRAUD_PHISH=0.334, FM_ASCII_ART_SPACINGc=0.833, RP_MATCHES_RCVD=-0.535] 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 EUMCrKlRGyk6; Thu, 23 Jan 2014 14:39:04 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 408181A0442; Thu, 23 Jan 2014 14:39:03 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id EEDEC26C631B; Thu, 23 Jan 2014 17:39:01 -0500 (EST)
From: Thomas Nadeau 
Content-Type: multipart/signed; boundary="Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Thu, 23 Jan 2014 17:39:01 -0500
Message-Id: 
To: draft-ietf-eman-energy-monitoring-mib@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Cc: "MIB Doctors \(E-mail\)" , list eman mailing 
Subject: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-monitoring-mib
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jan 2014 22:39:19 -0000

--Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	I reviewed this draft as part of the MIB Doctor review on =
Thursday, January 23, 2014.
My comments inline begin with TOM:

   General Comments on the draft:

   1) There are a number of id-nits warnings and one major error that =
will cause it to not pass:

      ** Obsolete normative reference: RFC 4133 (Obsoleted by RFC 6933)=20=


   2) In general, please go through the MIB modules and verify that the =
Integer32 values are indeed ok to be negative values or change them to =
Unsigned. For example, there are many instances where you used Integer32 =
for things like watts or amps where negative values do not make sense, =
to me at least.=20

   3)  There are a number of warnings in the smilint run. Please check =
and correct these.=20


IANA-POWERSTATE-SET-MIB:

[server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 =
./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB =
./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB =
./IANA-POWERSTATE-SET-MIB
./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' =
is already loaded, aborting parser on this file
./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be =
imported from module `SNMPv2-SMI'
./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: =
identifier `snmpEngineID' differs from `SnmpEngineID' only in case
./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous =
definition of `SnmpEngineID'
./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used
./IANA-POWERSTATE-SET-MIB:39: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./IANA-POWERSTATE-SET-MIB:4: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used

ENERGY-OBJECT-MIB:

[server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 =
./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB =
./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB =
./IANA-POWERSTATE-SET-MIB ./ENERGY-OBJECT-MIB
./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' =
is already loaded, aborting parser on this file
./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be =
imported from module `SNMPv2-SMI'
./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: =
identifier `snmpEngineID' differs from `SnmpEngineID' only in case
./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous =
definition of `SnmpEngineID'
./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used
./IANA-POWERSTATE-SET-MIB:39: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./IANA-POWERSTATE-SET-MIB:4: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used
./ENERGY-OBJECT-MIB:111: [1] {object-identifier-unknown} unknown object =
identifier label `energyMIB'
./ENERGY-OBJECT-MIB:620: [5] {index-element-accessible} warning: index =
element `eoEnergyParametersIndex' of row `eoEnergyParametersEntry' =
should be not-accessible in SMIv2 MIB
./ENERGY-OBJECT-MIB:7: [5] {import-unused} warning: identifier `mib-2' =
imported from module `SNMPv2-SMI' is never used
./ENERGY-OBJECT-MIB:10: [5] {import-unused} warning: identifier =
`DisplayString' imported from module `SNMPv2-TC' is never used
[server:libsmi-0.4.8/mibs/ietf] tnadeau%=20



POWER-ATTRIBTUES-MIB:

/ENERGY-OBJECT-MIB:111: [1] {object-identifier-unknown} unknown object =
identifier label `energyMIB'
./ENERGY-OBJECT-MIB:620: [5] {index-element-accessible} warning: index =
element `eoEnergyParametersIndex' of row `eoEnergyParametersEntry' =
should be not-accessible in SMIv2 MIB
./ENERGY-OBJECT-MIB:7: [5] {import-unused} warning: identifier `mib-2' =
imported from module `SNMPv2-SMI' is never used
./ENERGY-OBJECT-MIB:10: [5] {import-unused} warning: identifier =
`DisplayString' imported from module `SNMPv2-TC' is never used
./POWER-ATTRIBTUES-MIB:111: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./POWER-ATTRIBTUES-MIB:6: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used
./POWER-ATTRIBTUES-MIB:14: [5] {import-unused} warning: identifier =
`OwnerString' imported from module `RMON-MIB' is never used
[server:libsmi-0.4.8/mibs/ietf] tnadeau%=20


	2) The modules still assume they are under the energyMIB common =
OID; please add notes to the RFC editor/IANA for the proper assignment.


     Network Working Group                            M. Chandramouli=20
                                                            B. Claise=20
     Internet-Draft                               Cisco Systems, Inc.=20
     Intended Status: Standards Track                    B. Schoening=20
     Expires: June 13, 2014                    Independent Consultant=20
                                                           J. Quittek=20
                                                             T. Dietz=20
                                                      NEC Europe Ltd.=20
                                                    December 13, 2013=20
                                                                     =20
     =20
                        Power and Energy Monitoring MIB=20
                    draft-ietf-eman-energy-monitoring-mib-08=20

     Status of this Memo=20

        This Internet-Draft is submitted to IETF in full conformance=20
        with the provisions of BCP 78 and BCP 79.  =20
          =20
        Internet-Drafts are working documents of the Internet=20
        Engineering Task Force (IETF), its areas, and its working=20
        groups.  Note that other groups may also distribute working=20
        documents as Internet-Drafts. =20
        =20
        Internet-Drafts are draft documents valid for a maximum of six=20=

        months and may be updated, replaced, or obsoleted by other=20
        documents at any time.  It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as =20
        "work in progress." =20
        =20
        The list of current Internet-Drafts can be accessed at=20
        http://www.ietf.org/ietf/1id-abstracts.txt =20
        =20
        The list of Internet-Draft Shadow Directories can be accessed =20=

        at http://www.ietf.org/shadow.html =20
     =20
        This Internet-Draft will expire on June 2014.                    =
=20
















     =20
             Expires June 13, 2014            [Page 1]=20=

=0C     Internet-Draft    December 2013=20=

     =20
     =20
     Copyright Notice=20
     =20
        Copyright (c) 2013 IETF Trust and the persons identified as the=20=

        document authors.  All rights reserved.=20
        =20
        This document is subject to BCP 78 and the IETF Trust's Legal=20
        Provisions Relating to IETF Documents=20
        (http://trustee.ietf.org/license-info) in effect on the date of=20=

        publication of this document.  Please review these documents=20
        carefully, as they describe your rights and restrictions with=20
        respect to this document.  Code Components extracted from this=20=

        document must include Simplified BSD License text as described=20=

        in Section 4.e of the Trust Legal Provisions and are provided=20
        without warranty as described in the Simplified BSD License.=20
        =20
        =20
     Abstract=20

        This document defines a subset of the Management Information=20
        Base (MIB) for power and energy monitoring of devices. =20
        =20
     Conventions used in this document=20

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED"=20=

        "MAY", and "OPTIONAL" in this document are to be interpreted as=20=

        described in RFC 2119 [RFC2119].=20
        =20
        =20
        =20
        Table of Contents=20
        =20
        1. Introduction............................................. 3=20=

        2. The Internet-Standard Management Framework............... 4=20=

        3. Use Cases................................................ 4=20=

        4. Terminology.............................................. 4=20=

        5. Architecture Concepts Applied to the MIB Modules......... 5=20=

        5.1. Energy Object Information............................. 12=20=

        5.2. Power State........................................... 13=20=

              5.2.1. Power State Set................................14=20=

        5.3. Energy Object Usage Information....................... 14=20=

        5.4. Optional Power Usage Attributes....................... 15=20=

        5.5. Optional Energy Measurement........................... 15=20=

        5.6. Fault Management...................................... 19=20=

        6. Discovery............................................... 20=20=

        7. Link with the other IETF MIBs........................... 21=20=

     =20
     =20
               Expires June 13, 2014           [Page 2]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
           7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB..21=20=

           7.2. Link with the ENTITY-STATE MIB......................22=20=

           7.3. Link with the POWER-OVER-ETHERNET MIB...............22=20=

           7.4. Link with the UPS MIB...............................23=20=

           7.5. Link with the LLDP and LLDP-MED MIBs................24=20=

        8. Implementation Scenario................................. 25=20=

        9. Structure of the MIB.................................... 27=20=

        10. MIB Definitions........................................ 28=20=

        11. Implementation Status.................................. 69=20=

        11.1. SNMP Research........................................ 70=20=

        11.2. Cisco Systems........................................ 70=20=

        12. Security Considerations................................ 71=20=

        13. IANA Considerations.................................... 72=20=

        14. Contributors........................................... 73=20=

        12. Acknowledgment......................................... 73=20=

        13. References............................................. 74=20=

           13.1. Normative References...............................74=20=

           13.2. Informative References.............................75=20=

     =20

        =20
        =20
     1. Introduction=20

        This document defines a subset of the Management Information=20
        Base (MIB) for use in energy management of devices within or=20
        connected to communication networks.  The MIB modules in this=20
        document are designed to provide a model for energy management,=20=

        which includes monitoring for Power State and energy consumption=20=

        of networked elements.  This MIB takes into account the Energy=20=

        Management Framework [EMAN-FMWK], which in turn, is based on the=20=

        Requirements for Energy Management [RFC6988].=20
        =20
        Energy management is applicable to devices in communication=20
        networks. Target devices for this specification include (but are=20=

        not limited to): routers, switches, Power over Ethernet (PoE)=20
        endpoints, protocol gateways for building management systems,=20
        intelligent meters, home energy gateways, hosts and servers,=20
        sensor proxies, etc. Target devices and the use cases for Energy=20=

        Management are discussed in Energy Management Applicability=20
        Statement [EMAN-AS].=20
        =20
        Where applicable, device monitoring extends to the individual=20
        components of the device and to any attached dependent devices.=20=

        For example: A device can contain components that are=20
        independent from a power-state point of view, such as line=20
        cards, processor cards, hard drives.  A device can also have=20

     =20
     =20
               Expires June 13, 2014           [Page 3]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        dependent attached devices, such as a switch with PoE endpoints=20=

        or a power distribution unit with attached endpoints.=20
        =20
        =20
        =20
     2. The Internet-Standard Management Framework=20

        For a detailed overview of the documents that describe the=20
        current Internet-Standard Management Framework, please refer to=20=

        section 7 of RFC 3410 [RFC3410].=20

TOM: Generally speaking, I prefer to just include [RFC3410] here. =
Repeating it is...well, redundant.
        =20
        Managed objects are accessed via a virtual information store,=20
        termed the Management Information Base or MIB. MIB objects are=20=

        generally accessed through the Simple Network Management=20
        Protocol (SNMP).  Objects in the MIB are defined using the=20
        mechanisms defined in the Structure of Management Information=20
        (SMI).  This memo specifies MIB modules that are compliant to=20
        SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58,=20=

        RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].=20
        =20
        =20
     3. Use Cases=20

        Requirements for power and energy monitoring for networking=20
        devices are specified in [RFC6988].  The requirements in=20
        [RFC6988] cover devices typically found in communications=20
        networks, such as switches, routers, and various connected=20
        endpoints.  For a power monitoring architecture to be useful, it=20=

        should also apply to facility meters, power distribution units,=20=

        gateway proxies for commercial building control, home automation=20=

        devices, and devices that interface with the utility and/or=20
        smart grid.  Accordingly, the scope of the MIB modules in this=20=

        document is broader than that specified in [RFC6988]. Several=20
        use cases for Energy Management have been identified in the=20
        "Energy Management (EMAN) Applicability Statement" [EMAN-AS]. An=20=

        illustrative example scenario is presented in Section 8. =20
        =20
        =20
     4. Terminology=20

TOM: Rather than just repeating the terms here, where you typically show =
their definition, I suggest just refering to the framework and cutting =
the section down unless something is newly defined here.

       Please refer to [EMAN-FMWK] for the definitions of the=20
       following terminology used in this draft.  =20
                =20
                Energy Management =20
                          =20
                Energy Management System (EnMS) =20
                           =20
     =20
     =20
               Expires June 13, 2014           [Page 4]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                Energy Monitoring =20
                         =20
                Energy Control =20
                =20
                electrical equipment =20
                           =20
                non-electrical equipment (mechanical equipment) =20
                 =20
                device =20
                       =20
                component =20
        =20
                power inlet  =20
                =20
                power outlet  =20
                             =20
                energy  =20
                           =20
                power =20
                             =20
                demand  =20
        =20
                provide energy =20
        =20
                receive energy =20
                          =20
                meter (energy meter) =20
        =20
                battery =20
                 =20
                Power Interface  =20
                  =20
                Nameplate Power =20
             =20
                Power Attributes =20
                          =20
                Power Quality  =20
                           =20
                Power State =20
               =20
                Power State Set =20
     =20
        =20
     5. Architecture Concepts Applied to the MIB Modules=20

        This section describes the concepts specified in the Energy=20
        Management Framework [EMAN-FMWK] that pertain to power usage,=20
        with specific information related to the MIB module specified in=20=

     =20
     =20
               Expires June 13, 2014           [Page 5]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        this document.  This subsection maps to the different concepts=20=

        developed in the Energy Management Framework [EMAN-FMWK].=20
        =20
        The Energy Monitoring MIB has 2 independent MIB modules ENERGY-
        OBJECT-MIB and POWER-ATTRIBUTES-MIB. The first MIB module=20
        ENERGY-OBJECT-MIB is focused on measurement of power and energy.=20=

        The second MIB module POWER-ATTRIBUTES-MIB is focused on Power=20=

        Attributes measurements for Energy Objects.=20
        =20
        Devices and their sub-components can be modeled using the=20
        containment tree of the ENTITY-MIB [RFC6933]. In addition,=20
        ENERGY-OBJECT-CONTEXT-MIB MIB module [EMAN-AWARE-MIB] provides a=20=

        framework for modeling the relationship between Energy Objects.=20=

        It is conceivable to have implementations of ENERGY-OBJECT-
        CONTEXT-MIB and ENERGY-OBJECT-MIB for modeling the relationships=20=

        between Energy Objects and also monitoring the Energy=20
        consumption of those Energy Objects.  In some situations, it is=20=

        possible to have implementation of ENERGY-OBJECT-MIB along=20
        ENTITY-MIB V4 [RFC6933] with the Module compliance of=20
        entity4CRCompliance.  This compliance requires that the=20
        following 3 MIB objects from ENTITY-MIB [RFC6933]=20
        (entPhysicalIndex, entPhysicalName and entPhysicalUUID) MUST be=20=

        implemented.=20
        =20
        The ENERGY-OBJECT-MIB MIB module consists of five tables.  =20

        The first table is the eoMeterCapabilitiesTable.  It indicates=20=

        the instrumentation available for each Energy Object.  Thus, the=20=

        entries in this table indicate to the EnMS which other tables=20
        from the ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB are=20
        available for each Energy Object.  The eoMeterCapabilitiesTable=20=

        is indexed by entPhysicalIndex [RFC6933].=20
        =20
        The second table is the eoPowerTable.  It returns the power=20
        consumption of each Energy Object, as well as the units, sign,=20=

        measurement accuracy, and related objects.  The eoPowerTable is=20=

        indexed by entPhysicalIndex.=20
        =20
        The third table is the eoPowerStateTable.  For each Energy=20
        Object, it provides information and statistics about the=20
        supported Power States.  The eoPowerStateTable is indexed by=20
        entPhysicalIndex and eoPowerStateIndex.=20
        =20
        The fourth table is the eoEnergyParametersTable.  The entries in=20=

        this table configure the parameters of energy and demand=20
        measurement collection.  This table is indexed by=20
        eoEnergyParametersIndex. =20
        =20
     =20
     =20
               Expires June 13, 2014           [Page 6]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        The fifth table is the eoEnergyTable.  The entries in this table=20=

        provide the log the energy and demand information.  This table=20=

        is indexed by eoEnergyParametersIndex.=20
        =20
     =20
         eoMeterCapabilitiesTable(1)=20
          |=20
          +---eoMeterCapabilitiesEntry(1)[entPhysicalIndex]  =20
          |   |=20
          |   +---r-n  BITS             eoMeterCapability=20
          |    =20
               =20
         eoPowerTable(2)=20
          |=20
          +---eoPowerEntry(1) [entPhysicalIndex]=20
          |   | =20
          |   +---r-n Integer32         eoPower(1)=20
          |   +-- r-n Integer32         eoPowerNamePlate(2)=20
          |   +-- r-n UnitMultiplier    eoPowerUnitMultiplier(3)=20
          |   +-- r-n Integer32         eoPowerAccuracy(4)=20
          |   +-- r-n INTEGER           eoMeasurementCaliber(5)=20
          |   +-- r-n INTEGER           eoPowerCurrentType(6)=20
          |   +-- r-n INTEGER           eoPowerOrigin(7)=20
          |   +-- rwn IANAPowerStateSet eoPowerAdminState(8)=20
          |   +-- r-n IANAPowerStateSet eoPowerOperState(9)=20
          |   +-- r-n OwnerString       eoPowerStateEnterReason(10)=20
          |   =20
          |   =20
          +---eoPowerStateTable(3)=20
          |      +--eoPowerStateEntry(1)=20
          |      |     [entPhysicalIndex, eoPowerStateIndex] =20
          |      |=20
          |      +-- --n IANAPowerStateSet eoPowerStateIndex(1)=20
          |      +-- r-n Interger32        eoPowerStateMaxPower(2)=20
          |      +-- r-n UnitMultiplier =20
          |                      eoPowerStatePowerUnitMultiplier(3)=20
          |      +-- r-n TimeTicks         eoPowerStateTotalTime(4)=20
          |      +-- r-n Counter32         eoPowerStateEnterCount(5)=20
          |=20
     =20
          +eoEnergyParametersTable(4)=20
          +---eoEnergyParametersEntry(1) [eoEnergyParametersIndex]=20
          |   =20
          |   +-- --n PhysicalIndex       eoEnergyObjectIndex(1)=20
          |   +   r-n Integer32           eoEnergyParametersIndex(2)  =20=

          |   +-- r-n TimeInterval eoEnergyParametersIntervalLength(3)=20=

          |   +-- r-n Integer32    eoEnergyParametersIntervalNumber(4)=20=

          |   +-- r-n Integer32    eoEnergyParametersIntervalMode(5)=20
     =20
     =20
               Expires June 13, 2014           [Page 7]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
          |   +-- r-n TimeInterval eoEnergyParametersIntervalWindow(6)=20=

          |   +-- r-n Integer32    eoEnergyParametersSampleRate(7)=20
          |   +-- r-n RowStatus          eoEnergyParametersStatus(8)=20
          |      =20
          +eoEnergyTable(5)=20
          +---eoEnergyEntry(1) =20
          |    [eoEnergyParametersIndex,eoEnergyCollectionStartTime]=20
          |     =20
          |   +-- r-n TimeTicks      eoEnergyCollectionStartTime(1)=20
          |   +-- r-n Integer32      eoEnergyConsumed(2)=20
          |   +-- r-n Integer32      eoEnergyProvided(3)  =20
          |   +-- r-n Integer32      eoEnergyStored(4)=20
          |   +-- r-n UnitMultiplier eoEnergyUnitMultiplier(5)=20
          |   +-- r-n Integer32      eoEnergyAccuracy(6)=20
          |   +-- r-n Integer32      eoEnergyMaxConsumed(7)=20
          |   +-- r-n Integer32      eoEnergyMaxProduced(8)=20
          |   +-- r-n TimeTicks      eoEnergyDiscontinuityTime(9)=20
         =20
             =20
        The powerAttributesMIB consists of four tables.=20
        eoACPwrAttributesTable is indexed by  entPhysicalIndex.=20
        eoACPwrAttributesPhaseTable is indexed by entPhysicalIndex and=20=

        eoPhaseIndex. eoACPwrAttributesWyePhaseTable and=20
        eoACPwrAttributesDelPhaseTable are indexed by entPhysicalIndex=20=

        and eoPhaseIndex.=20
        =20
        eoACPwrAttributesTable(1)=20
          |=20
          +---eoACPwrAttributesEntry(1) [ entPhysicalIndex]=20
          |   |=20
          |   +---r-n INTEGER    eoACPwrAttributesConfiguration(1)=20
          |   +-- r-n Interger32 eoACPwrAttributesAvgVoltage(2)=20
          |   +-- r-n Integer32  eoACPwrAttributesAvgCurrent(3)=20
          |   +-- r-n Integer32  eoACPwrAttributesFrequency(4)=20
          |   +-- r-n UnitMultiplier =20
          |                eoACPwrAttributesPowerUnitMultiplier(5)=20
          |   +-- r-n Integer32  eoACPwrAttributesPowerAccuracy(6)=20
          |   +-- r-n Interger32   =20
          |                   eoACPwrAttributesTotalActivePower(7)=20
          |   +-- r-n Integer32  =20
          |                 eoACPwrAttributesTotalReactivePower(8)=20
          |   +-- r-n Integer32    =20
          |                 eoACPwrAttributesTotalApparentPower(9)=20
          |   +-- r-n Integer32    =20
          |                  eoACPwrAttributesTotalPowerFactor(10)=20
          |   +-- r-n Integer32  eoACPwrAttributesThdAmpheres(11)=20
          |     =20
          +eoACPwrAttributesPhaseTable(2)=20
     =20
     =20
               Expires June 13, 2014           [Page 8]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
          +---EoACPwrAttributesPhaseEntry(1)=20
          |     |  [ entPhysicalIndex, eoPhaseIndex]=20
          |     |=20
          |     +-- r-n Integer32  eoPhaseIndex(1)=20
          |     +-- r-n Integer32  =20
          |     |          eoACPwrAttributesPhaseAvgCurrent(2)=20
          |     +-- r-n Integer32  =20
          |     |          eoACPwrAttributesPhaseActivePower(3)=20
          |     +-- r-n Integer32  =20
          |     |          eoACPwrAttributesPhaseReactivePower(4)=20
          |     +-- r-n Integer32  =20
          |     |          eoACPwrAttributesPhaseApparentPower(5)=20
          |     +-- r-n Integer32 =20
          |     |          eoACPwrAttributesPhasePowerFactor(6)=20
          |     +-- r-n Integer32  =20
          |     |          eoACPwrAttributesPhaseImpedance(7)=20
          |     |=20
          +eoACPwrAttributesDelPhaseTable(3)=20
          +-- eoACPwrAttributesDelPhaseEntry(1) =20
          |     |   [entPhysicalIndex, eoPhaseIndex]=20
          |     |                           =20
          |     +-- r-n Integer32=20
          |     |    eoACPwrAttributesDelPhaseToNextPhaseVoltage(1)=20
          |     +-- r-n Integer32 =20
          |     | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage(2)=20
          |     +-- r-n Integer32  =20
                                 eoACPwrAttributesDelThdCurrent(3)=20
          |     |=20
          +eoACPwrAttributesWyePhaseTable(4)=20
          +-- eoACPwrAttributesWyePhaseEntry(1) =20
          |     |       [entPhysicalIndex, eoPhaseIndex]=20
          |     |                            =20
          |     +-- r-n Integer32 =20
          |     |     eoACPwrAttributesWyePhaseToNeutralVoltage(1)=20
          |     +-- r-n Integer32  =20
          |     |     eoACPwrAttributesWyePhaseCurrent(2)=20
          |     +-- r-n Integer32=20
          |     |  eoACPwrAttributesWyeThdPhaseToNeutralVoltage(3)=20
          |     .=20
               =20
                            =20
        A UML representation of the MIB objects in the two MIB modules=20=

        ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB are presented. =20
        =20
        =20
              +-------------------------+      =20
              |    Energy Object State  |  =20
              | ----------------------- | =20
     =20
     =20
               Expires June 13, 2014           [Page 9]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
              | eoPowerAdminState       | =20
              | eoPowerOperState        |    =20
              | eoPowerStateEnterReason |   =20
              +-------------------------+=20
                        |=20
                        |=20
                        v                 =20
              +-----------------------+=20
        |---> |  Energy Object ID (*) |=20
        |     | --------------------- |=20
        |     | entPhysicalIndex      |=20
        |     | entPhysicalName       |=20
        |     | entPhysicalUUID       |=20
        |     +-----------------------+=20
        |                         =20
        |     +-----------------------------+=20
        |---- |  Energy Object Measurement  |=20
        |     | --------------------------- |=20
        |     | eoPower                     |=20
        |     | eoPowerUnitMultiplier       |=20
        |     | eoPowerAccuracy             |=20
        |     +-----------------------------+=20
        |     =20
        |     +---------------------------+=20
        |---- |  Energy Object Attributes |=20
        |     | ------------------------- |=20
        |     | eoPowerNamePlate          |=20
        |     | eoPowerMeasurementCaliber |=20
        |     | eoPowerCurrentType        |=20
        |     | eoPowerOrigin             |=20
        |     +---------------------------+=20
        |                            =20
        |     +---------------------------------+  =20
        |---- | Energy Object State Statistics  |  =20
              |-------------------------------- |   =20
              | eoPowerStateMaxPower            |  =20
              | eoPowerStatePowerUnitMultiplier |=20
              | eoPowerStateTotalTime           |=20
              | eoPowerStateEnterCount          |   =20
              +---------------------------------+    =20
        =20
              Figure 1:UML diagram for energyObjectMIB   =20
                             =20
              (*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB=20
        =20
     =20
               +----------------------------------+ =20
               |    Energy ParametersTable        |=20
     =20
     =20
               Expires June 13, 2014          [Page 10]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
               | -------------------------------- |   =20
               | eoEnergyObjectIndex              |=20
               | eoEnergyParametersIndex          |=20
               | eoEnergyParametersIntervalLength |=20
               | eoEnergyParametersIntervalNumber |=20
               | eoEnergyParametersIntervalMode   |=20
               | eoEnergyParametersIntervalWindow |=20
               | eoEnergyParametersSampleRate     |=20
               | eoEnergyParametersStatus         |   =20
               +----------------------------------+        =20
                                   |=20
                                   V       =20
               +----------------------------------+          =20
               |    Energy Table                  |                      =
   =20
               | -------------------------------- |                      =
   =20
               | eoEnergyCollectionStartTime      |                      =
 =20
               | eoEnergyConsumed                 |=20
               | eoEnergyProvided                 |=20
               | eoEnergyStored                   |=20
               | eoEnergyUnitMultiplier           |=20
               | eoEnergyAccuracy                 |          =20
               | eoEnergyMaxConsumed              |=20
               | eoEnergyMaxProduced              |   =20
               | eoDiscontinuityTime              |   =20
               +----------------------------------+        =20
                                                 =20
                       =20
     =20
     =20
              +-----------------------+=20
        |---> |  Energy Object ID (*) |=20
        |     | --------------------- |=20
        |     | entPhysicalIndex      |=20
        |     | entPhysicalName       |=20
        |     | entPhysicalUUID       |=20
        |     +-----------------------+=20
        |                         =20
        |     +--------------------------------------+ =20
        |---- |  Power Attributes                    | =20
        |     | ------------------------------------ |  =20
        |     | eoACPwrAttributesConfiguration       |=20
        |     | eoACPwrAttributesAvgVoltage          |=20
        |     | eoACPwrAttributesAvgCurrent          |=20
        |     | eoACPwrAttributesFrequency           |=20
        |     | eoACPwrAttributesPowerUnitMultiplier |=20
        |     | eoACPwrAttributesPowerAccuracy       |=20
        |     | eoACPwrAttributesTotalActivePower    |=20
        |     | eoACPwrAttributesTotalReactivePower  |=20
     =20
     =20
               Expires June 13, 2014          [Page 11]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        |     | eoACPwrAttributesTotalApparentPower  |=20
        |     | eoACPwrAttributesTotalPowerFactor    |   =20
        |     | eoACPwrAttributesThdAmpheres         |=20
        |     +--------------------------------------+   =20
        |    =20
        |    =20
        |     +--------------------------------------+=20
        |---- |  Power Phase Attributes              | =20
        |     | ------------------------------------ |=20
        |     | eoPhaseIndex                         |=20
        |     | eoACPwrAttributesPhaseAvgCurrent     |=20
        |     | eoACPwrAttributesPhaseActivePower    |=20
        |     | eoACPwrAttributesPhaseReactivePower  | =20
        |     | eoACPwrAttributesPhaseApparentPower  | =20
        |     | eoACPwrAttributesPhasePowerFactor    |=20
        |     | eoACPwrAttributesPhaseImpedance      |=20
        |     +--------------------------------------+  =20
        |    =20
        |    =20
        |     +------------------------------------------------+=20
        |---- |  AC Input DEL Configuration                    |=20
        |     | ---------------------------------------------- |=20
        |     | eoACPwrAttributesDelPhaseToNextPhaseVoltage    |=20
        |     | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage |=20
        |     | eoACPwrAttributesDelThdCurrent                 |=20
        |     +------------------------------------------------+ =20
        |     =20
        |=20
        |     +----------------------------------------------+ =20
        |---- |  AC Input WYE Configuration                  |=20
              | -------------------------------------------- |=20
              | eoACPwrAttributesWyePhaseToNeutralVoltage    |=20
              | eoACPwrAttributesWyePhaseCurrent             |=20
              | eoACPwrAttributesWyeThdPhaseToNeutralVoltage |=20
              +----------------------------------------------+  =20
        =20
                Figure 2: UML diagram for the powerAttributesMIB =20
     =20
                 (*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB=20
     =20

     5.1. Energy Object Information=20

        The Energy Object identity information is specified in the=20
        ENERGY-OBJECT-CONTEXT-MIB MIB module [EMAN-AWARE-MIB] primary=20
        table, i.e. the eoTable.  In this table, the context of the=20
        Energy Object such as domain, role description, importance are=20=

        specified.  In addition, the ENERGY-OBJECT-CONTEXT-MIB module=20
     =20
     =20
               Expires June 13, 2014          [Page 12]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        specifies the relationship between Energy Objects.  There are=20
        several possible relationships between Energy Objects such as=20
        meteredBy, metering, poweredBy, powering, aggregatedBy, and=20
        aggregating as defined in the IANA-ENERGY-RELATION-MIB MIB=20
        module [EMAN-AWARE-MIB]. =20
     =20

     5.2. Power State=20

        An Energy Object may have energy conservation modes called Power=20=

        States.  Between the ON and OFF states of a device, there can be=20=

        several intermediate energy saving modes.  Those energy saving=20=

        modes are called as Power States. =20
        =20
        Power States, which represent universal states of power=20
        management of an Energy Object, are specified by the=20
        eoPowerState MIB object.  The actual Power State is specified by=20=

        the eoPowerOperState MIB object, while the eoPowerAdminState MIB=20=

        object specifies the Power State requested for the Energy=20
        Object.  The difference between the values of eoPowerOperState=20=

        and eoPowerAdminState can be attributed that the Energy Object=20=

        is busy transitioning from eoPowerAdminState into the=20
        eoPowerOperState, at which point it will update the content of=20=

        eoPowerOperState.  In addition, the possible reason for change=20=

        in Power State is reported in eoPowerStateEnterReason. =20
        Regarding eoPowerStateEnterReason, management stations and=20
        Energy Objects should support any format of the owner string=20
        dictated by the local policy of the organization.  It is=20
        suggested that this name contain at least the reason for the=20
        transition change, and one or more of the following: IP address,=20=

        management station name, network manager's name, location, or=20
        phone number.=20
        =20
        The MIB objects eoPowerOperState, eoPowerAdminState , and=20
        eoPowerStateEnterReason are contained in the eoPowerTable MIB=20
        table.=20
           =20
        The eoPowerStateTable table enumerates the maximum power usage=20=

        in watts, for every single supported Power State of each Power=20=

        State Set supported by the Energy Object.  In addition,=20
        PowerStateTable provides additional statistics:=20
        eoPowerStateEnterCount, the number of times an entity has=20
        visited a particular Power State, and eoPowerStateTotalTime, the=20=

        total time spent in a particular Power State of an Energy=20
        Object. =20
        =20
        =20

     =20
     =20
               Expires June 13, 2014          [Page 13]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
     5.2.1. Power State Set=20

        There are several standards and implementations of Power State=20=

        Sets.  An Energy Object can support one or multiple Power State=20=

        Set implementation(s) concurrently. =20
        =20
        There are currently three Power State Sets advocated:  =20
        =20
          IEEE1621      - [IEEE1621]=20
          DMTF          - [DMTF]=20
          EMAN          - [EMAN-FMWK]=20
     =20
        The Power State Sets, along with each Power State within the=20
        Power Set are listed in [EMAN-FMWK]. =20
        =20
     5.3. Energy Object Usage Information=20

        For an Energy Object, power usage is reported using eoPower. =20
        The magnitude of measurement is based on the=20
        eoPowerUnitMultiplier MIB variable, based on the UnitMultiplier=20=

        Textual Convention (TC). Power measurement magnitude should=20
        conform to the IEC 62053-21 [IEC.62053-21] and IEC 62053-22=20
        [IEC.62053-22] definition of unit multiplier for the SI (System=20=

        International) units of measure.  Measured values are=20
        represented in SI units obtained by BaseValue * 10 raised to the=20=

        power of the scale.  =20
          =20
        For example, if current power usage of an Energy Object is 3, it=20=

        could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of=20
        eoPowerUnitMultiplier.  Note that other measurements throughout=20=

        the two MIB modules in this document use the same mechanism,=20
        including eoPowerStatePowerUnitMultiplier,=20
        eoEnergyUnitMultiplier, and=20
        eoACPwrAttributesPowerUnitMultiplier.=20
        =20
        In addition to knowing the usage and magnitude, it is useful to=20=

        know how a eoPower measurement was obtained.  An NMS can use=20
        this to account for the accuracy and nature of the reading=20
        between different implementations.  For this eoPowerOrigin=20
        describes whether the measurements were made at the device=20
        itself or from a remote source.  The eoPowerMeasurementCaliber=20=

        describes the method that was used to measure the power and can=20=

        distinguish actual or estimated values.  There may be devices in=20=

        the network, which may not be able to measure or report power=20
        consumption.  For those devices, the object=20
        eoPowerMeasurementCaliber shall report that measurement=20
        mechanism is "unavailable" and the eoPower measurement shall be=20=

        "0". =20
     =20
     =20
               Expires June 13, 2014          [Page 14]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
        The nameplate power rating of an Energy Object is specified in=20=

        eoPowerNameplate MIB object.=20
        =20
        =20
     5.4. Optional Power Usage Attributes =20

        The optional powerAttributesMIB MIB module can be implemented to=20=

        further describe power usage attributes measurement.  The=20
        powerAttributesMIB MIB module adheres closely to the IEC 61850=20=

        7-2 standard to describe AC measurements.  =20
        =20
        The powerAttributesMIB MIB module contains a primary table, the=20=

        eoACPwrAttributesTable table, that defines power attributes=20
        measurements for supported entPhysicalIndex entities, as a=20
        sparse extension of the eoPowerTable (with entPhysicalIndex as=20=

        primary index).  This eoACPwrAttributesTable table contains such=20=

        information as the configuration (single phase, DEL 3 phases,=20
        WYE 3 phases), voltage, frequency, power accuracy, total=20
        active/reactive power/apparent power, amperage, and voltage. =20
        =20
        In case of 3-phase power, the eoACPwrAttributesPhaseTable=20
        additional table is populated with Power Attributes measurements=20=

        per phase (so double indexed by the entPhysicalIndex and=20
        eoPhaseIndex).  This table, which describes attributes common to=20=

        both WYE and DEL configurations, contains the average current,=20=

        active/reactive/apparent power, power factor, and impedance.=20
        =20
        In case of 3-phase power with a DEL configuration, the=20
        eoACPwrAttributesDelPhaseTable table describes the phase-to-
        phase  power attributes measurements, i.e., voltage and current.=20=

        =20
        In case of 3-phase power with a WYE configuration, the=20
        eoACPwrAttributesWyePhaseTable table describes the phase-to-
        neutral power attributes measurements, i.e., voltage and=20
        current.=20
        =20
     5.5. Optional Energy Measurement=20

        It is relevant to measure energy and demand only when there are=20=

        actual power measurements obtained from measurement hardware. If=20=

        the eoPowerMeasurementCaliber MIB object has values of=20
        unavailable, unknown, estimated, or presumed, then the energy=20
        and demand values are not useful.=20
        =20
        Two tables are introduced to characterize energy measurement of=20=

        an Energy Object: eoEnergyTable and eoEnergyParametersTable. =20
        Both energy and demand information can be represented via the=20
     =20
     =20
               Expires June 13, 2014          [Page 15]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        eoEnergyTable.  Energy information will be an accumulation with=20=

        no interval.  Demand information can be represented. =20
        The eoEnergyParametersTable consists of the parameters defining =20=

        eoEnergyParametersIndex an index of that specifies the setting=20=

        for collection of energy measurements for an Energy Object,=20
        eoEnergyObjectIndex linked to the entPhysicalIndex of the=20
        Energy Object, the duration of measurement intervals in seconds,=20=

        (eoEnergyParametersIntervalLength), the number of successive=20
        intervals to be stored in the eoEnergyTable,=20
        (eoEnergyParametersIntervalNumber), the type of measurement=20
        technique (eoEnergyParametersIntervalMode), and a sample rate=20
        used to calculate the average (eoEnergyParametersSampleRate). =20=

        Judicious choice of the sampling rate will ensure accurate=20
        measurement of energy while not imposing an excessive polling=20
        burden.=20
          =20
        There are three eoEnergyParametersIntervalMode types used for=20
        energy measurement collection: period, sliding, and total.  The=20=

        choices of the three different modes of collection are based on=20=

        IEC standard 61850-7-4.  Note that multiple=20
        eoEnergyParametersIntervalMode types MAY be configured=20
        simultaneously.  It is important to note that for a given Energy=20=

        Object, multiple modes (periodic, total, sliding window) of=20
        energy measurement collection can be configured with the use of=20=

        eoEnergyParametersIndex.  However, simultaneous measurement in=20=

        multiple modes for a given Energy Object depends on the Energy=20=

        Object capability. =20
     =20
        These three eoEnergyParametersIntervalMode types are illustrated=20=

        by the following three figures, for which:=20
        =20
        - The horizontal axis represents the current time, with the=20
        symbol <--- L ---> expressing the=20
        eoEnergyParametersIntervalLength, and the=20
        eoEnergyCollectionStartTime is represented by S1, S2, S3, S4,=20
        ..., Sx where x is the value of=20
        eoEnergyParametersIntervalNumber.=20
        =20
        - The vertical axis represents the time interval of sampling and=20=

        the value of eoEnergyConsumed can be obtained at the end of the=20=

        sampling period.  The symbol =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
denotes the duration of=20
        the sampling period. =20
        =20
     =20
              |             |             | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D |    =20
              |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |             |      =
       |  =20
              |             |             |             |=20
              |             |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |      =
       |=20
     =20
     =20
               Expires June 13, 2014          [Page 16]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
              |             |             |             |=20
              | <--- L ---> | <--- L ---> | <--- L ---> |=20
              |             |             |             |=20
             S1            S2            S3             S4=20
        =20
                Figure 3 : Period eoEnergyParametersIntervalMode=20
        =20
        A eoEnergyParametersIntervalMode type of 'period' specifies non-
        overlapping periodic measurements.  Therefore, the next=20
        eoEnergyCollectionStartTime is equal to the previous=20
        eoEnergyCollectionStartTime plus=20
        eoEnergyParametersIntervalLength. S2=3DS1+L; S3=3DS2+L, ...=20
        =20
        =20
                       |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |           =
=20
                       |             |          =20
                       | <--- L ---> |       =20
                       |             |        =20
                       |   |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |     =20=

                       |   |             |=20
                       |   | <--- L ---> |    =20
                       |   |             |          =20
                       |   |   |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | =20=

                       |   |   |             |             =20
                       |   |   | <--- L ---> | =20
                       |   |   |             |     =20
                       |   |   |   |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
| =20
                       |   |   |   |             |   =20
                       |   |   |   | <--- L ---> |=20
                      S1   |   |   |             |=20
                           |   |   |             |=20
                           |   |   |             |=20
                          S2   |   |             |=20
                               |   |             |=20
                               |   |             |=20
                              S3   |             |=20
                                   |             |=20
                                   |             |=20
                                  S4=20
        =20
               Figure 4 : Sliding eoEnergyParametersIntervalMode=20
        =20
        A eoEnergyParametersIntervalMode type of 'sliding' specifies=20
        overlapping periodic measurements.=20
     =20
        =20
     =20
        |                          |=20
     =20
     =20
               Expires June 13, 2014          [Page 17]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D |=20
        |                          |=20
        |                          |=20
        |                          |=20
        |  <--- Total length --->  |=20
        |                          |=20
                         S1            =20
        =20
                Figure 5  : Total eoEnergyParametersIntervalMode=20
        =20
        A eoEnergyParametersIntervalMode type of 'total' specifies a=20
        continuous measurement since the last reset.  The value of=20
        eoEnergyParametersIntervalNumber should be (1) one and=20
        eoEnergyParametersIntervalLength is ignored.=20
        =20
        The eoEnergyParametersStatus is used to start and stop energy=20
        usage logging.  The status of this variable is "active" when all=20=

        the objects in eoEnergyParametersTable are appropriate which in=20=

        turn indicates if eoEnergyTable entries exist or not.=20
        =20
        The eoEnergyTable consists of energy measurements in=20
        eoEnergyConsumed, eoEnergyProvided and eoEnergyStored, the units=20=

        of the measured energy eoEnergyUnitMultiplier, and the maximum=20=

        observed energy within a window eoEnergyMaxConsumed,=20
        eoEnergyMaxProduced.   =20
        =20
        Measurements of the total energy consumed by an Energy Object=20
        may suffer from interruptions in the continuous measurement of=20=

        energy consumption.  In order to indicate such interruptions,=20
        the object eoEnergyDiscontinuityTime is provided for indicating=20=

        the time of the last interruption of total energy measurement. =20=

        eoEnergyDiscontinuityTime shall indicate the sysUpTime [RFC3418]=20=

        when the device was reset. =20
        =20
        The following example illustrates the eoEnergyTable and=20
        eoEnergyParametersTable:=20
        =20
        First, in order to estimate energy, a time interval to sample=20
        energy should be specified, i.e.=20
        eoEnergyParametersIntervalLength can be set to "900 seconds" or=20=

        15 minutes and the number of consecutive intervals over which=20
        the maximum energy is calculated=20
        (eoEnergyParametersIntervalNumber) as "10".  The sampling rate=20=

        internal to the Energy Object for measurement of power usage=20
        (eoEnergyParametersSampleRate) can be "1000 milliseconds", as=20
        set by the Energy Object as a reasonable value.  Then, the=20
        eoEnergyParametersStatus is set to active (value 1) to indicate=20=


     =20
     =20
               Expires June 13, 2014          [Page 18]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        that the Energy Object should start monitoring the usage per the=20=

        eoEnergyTable.=20
        =20
        The indices for the eoEnergyTable are eoEnergyParametersIndex=20
        which identifies the index for the setting of energy measurement=20=

        collection Energy Object, and eoEnergyCollectionStartTime, which=20=

        denotes the start time of the energy measurement interval based=20=

        on sysUpTime [RFC3418].  The value of eoEnergyComsumed is the=20
        measured energy consumption over the time interval specified=20
        (eoEnergyParametersIntervalLength) based on the Energy Object=20
        internal sampling rate (eoEnergyParametersSampleRate).  While=20
        choosing the values for the eoEnergyParametersIntervalLength and=20=

        eoEnergyParametersSampleRate, it is recommended to take into=20
        consideration either the network element resources adequate to=20=

        process and store the sample values, and the mechanism used to=20=

        calculate the eoEnergyConsumed.  The units are derived from=20
        eoEnergyUnitMultiplier.  For example, eoEnergyConsumed can be=20
        "100" with eoEnergyUnitMultiplier  equal to 0, the measured=20
        energy consumption of the Energy Object is 100 watt-hours.  The=20=

        eoEnergyMaxConsumed is the maximum energy observed and that can=20=

        be "150 watt-hours".=20
        =20
        The eoEnergyTable has a buffer to retain a certain number of=20
        intervals, as defined by eoEnergyParametersIntervalNumber.  =20
        If the default value of "10" is kept, then the eoEnergyTable=20
        contains 10 energy measurements, including the maximum.  =20
        =20
        Here is a brief explanation of how the maximum energy can be=20
        calculated.  The first observed energy measurement value is=20
        taken to be the initial maximum.  With each subsequent=20
        measurement, based on numerical comparison, maximum energy may=20=

        be updated.  The maximum value is retained as long as the=20
        measurements are taking place.  Based on periodic polling of=20
        this table, an NMS could compute the maximum over a longer=20
        period, i.e. a month, 3 months, or a year.=20
     =20

     5.6. Fault Management=20

        [RFC6988] specifies requirements about Power States such as "the=20=

        current Power State" , "the time of the last state change", "the=20=

        total time spent in each state", "the number of transitions to=20=

        each state" etc.  Some of these requirements are fulfilled=20
        explicitly by MIB objects such as eoPowerOperState,=20
        eoPowerStateTotalTime and eoPowerStateEnterCount.  Some of the=20=

        other requirements are met via the SNMP NOTIFICATION mechanism. =20=

        eoPowerStateChange SNMP notification which is generated when the=20=


     =20
     =20
               Expires June 13, 2014          [Page 19]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        value(s) of ,eoPowerStateIndex, eoPowerOperState,=20

TOM: Odd spacing of the comma above.

        eoPowerAdminState have changed. =20
        =20
         =20
     6. Discovery=20

        It is foreseen that most Energy Objects will require the=20
        implementation of the ENERGY-OBJECT-CONTEXT-MIB MIB [EMAN-AWARE-
        MIB] as a prerequisite for this MIB module.  In such a case,=20
        eoPowerTable of the EMAN-MON-MIB is a sparse extension of the=20
        eoTable of ENERGY-OBJECT-CONTEXT-MIB.  Every Energy Object MUST=20=

        implement entPhysicalIndex, entPhysicalUUID  and entPhysicalName=20=

        from the ENTITY-MIB [RFC6933].  As the primary index for the=20
        Energy Object, entPhysicalIndex is used: It characterizes the=20
        Energy Object in the ENERGY-OBJECT-MIB and the POWER-ATTRIBUTES-
        MIB MIB modules (this document).=20

        The NMS must first poll the ENERGY-OBJECT-CONTEXT-MIB MIB module=20=

        [EMAN-AWARE-MIB], if available, in order to discover all the=20
        Energy Objects and the relationships between those Energy=20
        Objects. In the ENERGY-OBJECT-CONTEXT-MIB module tables, the=20
        Energy Objects are indexed by the entPhysicalIndex.=20

        =46rom there, the NMS must poll the eoPowerStateTable (specified=20=

        in the ENERGY-OBJECT-MIB module in this document), which=20
        enumerates, amongst other things, the maximum power usage.  As=20=

        the entries in eoPowerStateTable table are indexed by the =20
        Energy Object ( entPhysicalIndex), by the Power State Set=20
        (eoPowerStateIndex), the maximum power usage is discovered per =20=

        Energy Object, and the power usage per Power State of the Power=20=

        State Set.  In other words, polling the eoPowerStateTable allows=20=

        the discovery of each Power State within every Power State Set=20=

        supported by the Energy Object.              =20

        If the Energy Object has an Aggregation Relationship with=20
        another Energy Object, the MIB module would be populated with=20
        the Energy Object relationship information, which have their own=20=

        Energy Object index value (entPhysicalIndex). However, the=20
        Energy Object relationship must be discovered thanks to the=20
        ENERGY-OBJECT-CONTEXT-MIB module. =20

        Finally, the NMS can monitor the power attributes thanks to the=20=

        powerAttributesMIB MIB module, which reuses the entPhysicalIndex=20=

        to index the Energy Object.=20

                                     =20


     =20
     =20
               Expires June 13, 2014          [Page 20]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
     7. Link with the other IETF MIBs=20

        =20
     7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB =20

        RFC 4133 [RFC4133] defines the ENTITY-MIB module that lists the=20=

        physical entities of a networking device (router, switch, etc.)=20=

        and those physical entities indexed by entPhysicalIndex.  =46rom=20=

        an energy-management standpoint, the physical entities that=20
        consume or produce energy are of interest.=20
        =20
        RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module that=20
        provides a standardized way of obtaining information (current=20
        value of the sensor, operational status of the sensor, and the=20=

        data units precision) from sensors embedded in networking=20
        devices.  Sensors are associated with each index of=20
        entPhysicalIndex of the ENTITY-MIB [RFC4133].  While the focus=20=

        of the Power and Energy Monitoring MIB is on measurement of=20
        power usage of networking equipment indexed by the ENTITY-MIB,=20=

        this MIB proposes a customized power scale for power measurement=20=

        and different Power States of networking equipment, and=20
        functionality to configure the Power States.=20
        =20
        The Energy Objects are modeled by the entPhysicalIndex through=20=

        the entPhysicalEntity MIB object specified in the eoTable in the=20=

        ENERGY-OBJECT-CONTEXT-MIB MIB module [EMAN-AWARE-MIB].  =20

        The ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x=20
        accuracy classes required for electricity (i.e., 1%, 2%, 0.5%=20
        accuracy classes). Indeed, entPhySensorPrecision [RFC3433]=20
        represents "The number of decimal places of precision in fixed-
        point sensor values returned by the associated entPhySensorValue=20=

        object".  The ANSI and IEC Standards are used for power=20
        measurement and these standards require that we use an accuracy=20=

        class, not the scientific-number precision model specified in=20
        RFC3433.  The eoPowerAccuracy MIB object models this accuracy. =20=

        Note that eoPowerUnitMultipler represents the scale factor per=20=

        IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22],=20
        which is a more logical representation for power measurements=20
        (compared to entPhySensorScale), with the mantissa and the=20
        exponent values X * 10 ^ Y.=20

        Power measurements specifying the qualifier 'UNITS' for each=20
        measured value in watts are used in the LLDP-EXT-MED-MIB, POE=20
        [RFC3621], and UPS [RFC1628] MIBs.  The same 'UNITS' qualifier=20=

        is used for the power measurement values.   =20
        =20

     =20
     =20
               Expires June 13, 2014          [Page 21]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        One cannot assume that the ENTITY-MIB and ENTITY-SENSOR MIB are=20=

        implemented for all Energy Objects that need to be monitored.  A=20=

        typical example is a converged building gateway, monitoring=20
        several other devices in the building, doing the proxy between=20=

        SNMP and a protocol like BACNET.  Another example is the home=20
        energy controller.  In such cases, the eoPhysicalEntity value=20
        contains the zero value, thanks to PhysicalIndexOrZero textual=20=

        convention.=20
        =20
        The eoPower is similar to entPhySensorValue [RFC3433] and the=20
        eoPowerUnitMultipler is similar to entPhySensorScale.=20
        =20
        =20
     7.2. Link with the ENTITY-STATE MIB =20

        For each entity in the ENTITY-MIB [RFC4133], the ENTITY-STATE=20
        MIB [RFC4268] specifies the operational states (entStateOper:=20
        unknown, enabled, disabled, testing), the alarm (entStateAlarm:=20=

        unknown, underRepair, critical, major, minor, warning,=20
        indeterminate) and the possible values of standby states =20
        (entStateStandby: unknown, hotStandby, coldStandby,=20
        providingService).=20
        =20
        =46rom a power monitoring point of view, in contrast to the =
entity=20
        operational states of entities, Power States are required, as=20
        proposed in the Power and Energy Monitoring MIB module.  Those=20=

        Power States can be mapped to the different operational states=20=

        in the ENTITY-STATE MIB, if a formal mapping is required.  For=20=

        example, the entStateStandby "unknown", "hotStandby",=20
        "coldStandby", states could map to the Power State "unknown",=20
        "ready", "standby", respectively, while the entStateStandby=20
        "providingService" could map to any "low" to "high" Power State.=20=

        =20
        =20
     7.3. Link with the POWER-OVER-ETHERNET MIB=20

        Power-over-Ethernet MIB [RFC3621] provides an energy monitoring=20=

        and configuration framework for power over Ethernet devices. =20
        The RFC introduces a concept of a port group on a switch to=20
        define power monitoring and management policy and does not use=20=

        the entPhysicalIndex as the index.  Indeed, the=20
        pethMainPseConsumptionPower is indexed by the=20
        pethMainPseGroupIndex, which has no mapping with the=20
        entPhysicalIndex. =20
        =20
        One cannot assume that the Power-over-Ethernet MIB is=20
        implemented for all Energy Objects that need to be monitored.  =20=


     =20
     =20
               Expires June 13, 2014          [Page 22]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        A typical example is a converged building gateway, monitoring=20
        several other devices in the building, doing the proxy between=20=

        SNMP and a protocol like BACNET.  Another example is the home=20
        energy controller.  In such cases, the eoethPortIndex and=20
        eoethPortGrpIndex values contain the zero value, thanks to new=20=

        PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero=20=

        conventions.=20
        =20
        However, if the Power-over-Ethernet MIB [RFC3621] is supported,=20=

        the Energy Object eoethPortIndex and eoethPortGrpIndex contain=20=

        the pethPsePortIndex and pethPsePortGroupIndex, respectively.=20
        =20
        As a consequence, the entPhysicalIndex MIB object has been kept=20=

        as the unique Energy Object index.=20
        =20
        Note that, even though the Power-over-Ethernet MIB [RFC3621] was=20=

        created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse=20=

        the precision notion from the ENTITY-SENSOR MIB, i.e. the=20
        entPhySensorPrecision MIB object.=20
        =20
         =20
     7.4. Link with the UPS MIB=20

        To protect against unexpected power disruption, data centers and=20=

        buildings make use of Uninterruptible Power Supplies (UPS).  To=20=

        protect critical assets, a UPS can be restricted to a particular=20=

        subset or domain of the network.  UPS usage typically lasts only=20=

        for a finite period of time, until normal power supply is=20
        restored.  Planning is required to decide on the capacity of the=20=

        UPS based on output power and duration of probable power outage. =
=20
        To properly provision UPS power in a data center or building, it=20=

        is important to first understand the total demand required to=20
        support all the entities in the site.  This demand can be=20
        assessed and monitored via the Power and Energy Monitoring MIB. =20=


        UPS MIB [RFC1628] provides information on the state of the UPS=20=

        network.  Implementation of the UPS MIB is useful at the=20
        aggregate level of a data center or a building.  The MIB module=20=

        contains several groups of variables:=20

        - upsIdent: Identifies the UPS entity (name, model, etc.). =20

        - upsBattery group: Indicates the battery state=20
        (upsbatteryStatus, upsEstimatedMinutesRemaining, etc.)=20

        - upsInput group: Characterizes the input load to the UPS=20
        (number of input lines, voltage, current, etc.).=20

     =20
     =20
               Expires June 13, 2014          [Page 23]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        - upsOutput: Characterizes the output from the UPS (number of=20
        output lines, voltage, current, etc.)=20

        - upsAlarms: Indicates the various alarm events.  =20

        The measurement of power in the UPS MIB is in Volts, Amperes and=20=

        Watts.  The units of power measurement are RMS volts and RMS=20
        Amperes. They are not based on the EntitySensorDataScale and=20
        EntitySensorDataPrecision of ENTITY-SENSOR-MIB.=20

        Both the Power and Energy Monitoring MIB and the UPS MIB may be=20=

        implemented on the same UPS SNMP agent, without conflict.  In=20
        this case, the UPS device itself is the Energy Object  and any=20=

        of the UPS meters or submeters are the Energy Objects with a=20
        possible relationship as defined in [EMAN-FMWK].=20
        =20
     7.5. Link with the LLDP and LLDP-MED MIBs=20

        The LLDP Protocol is a Data Link Layer protocol used by network=20=

        devices to advertise their identities, capabilities, and=20
        interconnections on a LAN network. =20
        =20
        The Media Endpoint Discovery is an enhancement of LLDP, known as=20=

        LLDP-MED.  The LLDP-MED enhancements specifically address voice=20=

        applications.  LLDP-MED covers 6 basic areas: capability=20
        discovery, LAN speed and duplex discovery, network policy=20
        discovery, location identification discovery, inventory=20
        discovery, and power discovery.  =20
        =20
        Of particular interest to the current MIB module is the power=20
        discovery, which allows the endpoint device (such as a PoE=20
        phone) to convey power requirements to the switch.  In power=20
        discovery, LLDP-MED has four Type Length Values (TLVs): power=20
        type, power source, power priority and power value. =20
        Respectively, those TLVs provide information related to the type=20=

        of power (power sourcing entity versus powered device), how the=20=

        device is powered (from the line, from a backup source, from=20
        external power source, etc.), the power priority (how important=20=

        is it that this device has power?), and how much power the=20
        device needs.=20
         =20
        The power priority specified in the LLDP-MED MIB [LLDP-MED-MIB]=20=

        actually comes from the Power-over-Ethernet MIB [RFC3621]. If=20
        the Power-over-Ethernet MIB [RFC3621] is supported, the exact=20
        value from the pethPsePortPowerPriority [RFC3621] is copied over=20=

        in the lldpXMedRemXPoEPDPowerPriority [LLDP-MED-MIB]; otherwise=20=

        the value in lldpXMedRemXPoEPDPowerPriority is "unknown". =46rom=20=

        the Power and Energy Monitoring MIB, it is possible to identify=20=

     =20
     =20
               Expires June 13, 2014          [Page 24]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        the pethPsePortPowerPriority [RFC3621], thanks to the=20
        eoethPortIndex and eoethPortGrpIndex.=20
        =20
        The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to=20
        eoPowerOrigin in indicating if the power for an attached device=20=

        is local or from a remote device. If the LLDP-MED MIB is=20
        supported, the following mapping can be applied to the=20
        eoPowerOrigin: lldpXMedLocXPoEPDPowerSource fromPSE(2) and=20
        local(3) can be mapped to remote(2) and self(1), respectively.=20=

     =20

     8. Implementation Scenario=20

        This section provides an illustrative example scenario for the=20=

        implementation of the Energy Object, including Energy Object=20
        relationships. =20
        =20
        Example Scenario of a campus network: Switch with PoE Endpoints=20=

        with further connected devices. =20
        =20
        The campus network consists of switches that provide LAN=20
        connectivity.  The switch with PoE ports is located in wiring=20
        closet.  PoE IP phones are connected to the switch.  The IP=20
        phones draw power from the PoE ports of the switch.  In=20
        addition, a PC is daisy-chained from the IP phone for LAN=20
        connectivity.  =20
        =20
        The IP phone consumes power from the PoE switch, while the PC=20
        consumes power from the wall outlet. =20
        =20
        The switch has implementations of ENTITY-MIB [RFC6933] and=20
        ENERGY-OBJECT-CONTEXT-MIB  MIB [EMAN-AWARE-MIB]. while the PC=20
        has an implementation of the ENTITY-MIB with=20
        entity4CRCompliance, and an implementation of ENERGY-OBJECT-
        CONTEXT-MIB  MIB [EMAN-AWARE-MIB]. The switch has the following=20=

        attributes, entPhysicalIndex "1", and entPhysicalUUID  "UUID=20
        1000".  The power usage of the switch is "440 Watts".=20
        =20
        The PoE switch port has the following attributes: The switch=20
        port has entPhysicalIndex "3", and entPhysicalUUID is "UUID=20
        1000:3".  The power metered at the POE switch port is "12=20
        watts".  In this example, the POE switch port has an Energy=20
        Object relationship with the switch with Energy Object index=20
        "1000".=20
     =20
        The attributes of the PC are given below. The PC  has an=20
        entPhysicalIndex "7" and its entPhysicalUUID is "UUID 1000:57 ". =
=20
        The PC has an Energy Object relationship with the switch port=20
     =20
     =20
               Expires June 13, 2014          [Page 25]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        whose entPhysicalUUID is "UUID 1000:3".  The power usage of the=20=

        PC is "120 Watts" and is communicated to the switch port. =20
        =20
        The IP phone draws power from the switch, while the PC has LAN=20=

        connectivity from the phone, but is powered from the wall=20
        outlet.  However, the Energy Object switch sends power control=20=

        messages to both the Energy Object (IP phone and PC) and the=20
        attached remote Energy Objects react to those messages.=20
     =20
        =20
        |-------------------------------------------------------|=20
        |                            Switch                     |=20
        |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D|=20
        |  Switch        |  Switch     |            | Switch    |=20
        | entPhyIndx     |  UUID       |            | eoPower   |=20
        | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D |=20
        |     1          |  UUID 1000  |    null    |   440     |=20
        | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D |=20
        |                                                       |=20
        |                           SWITCH PORT                 |=20
        | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D |=20
        | | Switch      |   Switch     | Switch     | Switch    |=20
        | | Port        |    Port      |   UUID     | Port      |=20
        | | entPhyIndx  |    UUID      |            | eoPower   |=20
        | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D |=20
        | |    3        | UUID 1000:3  | 1000       |  12       |=20
        | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D|=20
        |                                   ^                   |=20
        |                                   |                   |=20
        |-----------------------------------|-------------------|=20
                                            |=20
                                            |=20
                          POE IP PHONE      |=20
                                            |=20
                                            |=20
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=20
        | IP phone    | IP phone    |   Port      |  IP phone | =20
        | entPhyIndx  | UUID        |   UUID      |  eoPower  |=20
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D =20
        |  Null       | UUID 1000:31| UUID 1000:3 |  12       |=20
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=20
                                             |=20
                                             |=20
        PC connected to switch via IP phone  |=20
                                             |=20
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=20
        | PC         | PC          |  Port       | PC       |=20
        |entPhyIndx  | UUID        |  UUID       | eoPower  |=20
     =20
     =20
               Expires June 13, 2014          [Page 26]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=20
        |  7         | UUID 1000:57| UUID 1000:3 | 120      |  =20
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=20
                              =20

                     Figure 6:  Example scenario =20

        =20
     =20
     9. Structure of the MIB=20

        The primary MIB object in this MIB module is the=20
        energyObjectMIBObject. The eoPowerTable table of=20
        energyObjectMIBObject describes the power measurement attributes=20=

        of an Energy Object entity. The notion of identity of the device=20=

        in terms of uniquely identification of the Energy Object and its=20=

        relationship to other entities in the network are addressed in=20=

        [EMAN-AWARE-MIB]. =20
        =20
        Logically, this MIB module is a sparse extension of the=20
        ENERGY-OBJECT-CONTEXT-MIB module [EMAN-AWARE-MIB]. Thus the=20
        following requirements which are applied to [EMAN-AWARE-MIB] are=20=

        also applicable. As a requirement for this MIB module, [EMAN-
        AWARE-MIB] should be implemented and as Module Compliance of=20
        ENTITY-MIB V4 [RFC6933] with respect to entity4CRCompliance=20
        should be supported which requires 3 MIB objects=20
        (entPhysicalIndex, entPhysicalName and entPhysicalUUID ) MUST be=20=

        implemented. =20
         =20
        eoMeterCapabilitiesTable is useful to enable applications to=20
        determine the capabilities supported by the local management=20
        agent.  This table indicates the energy monitoring MIB groups=20
        that are supported by the local management system. By reading=20
        the value of this object, it is possible for applications to=20
        know which tables contain the information and are usable without=20=

        walking through the table and querying every element which=20
        involves a trial-and-error process.=20
     =20
        The power measurement of an Energy Object contains information=20=

        describing its power usage (eoPower) and its current Power State=20=

        (eoPowerOperState).  In addition to power usage, additional=20
        information describing the units of measurement=20
        (eoPowerAccuracy, eoPowerUnitMultiplier), how power usage=20
        measurement was obtained  (eoPowerMeasurementCaliber), the=20
        source of power (eoPowerOrigin) and the type of power=20
        (eoPowerCurrentTtype) are described.=20
     =20

     =20
     =20
               Expires June 13, 2014          [Page 27]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        An Energy Object may contain an optional eoPowerAttributes table=20=

        that describes the electrical characteristics associated with=20
        the current Power State and usage.=20
        =20
        An Energy Object may contain an optional eoEnergyTable to=20
        describe energy measurement information over time.=20
        =20
        An Energy Object may also contain optional battery information=20=

        associated with this entity. =20
        =20
     =20
        =20
     10. MIB Definitions=20

        =20
        -- ************************************************************=20=

        -- =20
        --   =20
        -- This MIB is used to monitor power usage of network=20
        -- devices=20
        --   =20
        -- *************************************************************=20=

        =20
        ENERGY-OBJECT-MIB DEFINITIONS ::=3D BEGIN=20
        =20
        IMPORTS=20
            MODULE-IDENTITY,=20
            OBJECT-TYPE,=20
            NOTIFICATION-TYPE,=20
            mib-2,=20
            Integer32,  Counter32, TimeTicks   =20
                FROM SNMPv2-SMI=20
            TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval,=20=

            TimeStamp, TruthValue           =20
                FROM SNMPv2-TC    =20
            MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP=20
                FROM SNMPv2-CONF=20
            OwnerString=20
                FROM RMON-MIB=20
            entPhysicalIndex, PhysicalIndex=20
               FROM ENTITY-MIB   =20
            IANAPowerStateSet                 =20
               FROM IANA-POWERSTATE-SET-MIB;=20
        =20
        =20
        energyObjectMIB MODULE-IDENTITY=20
            LAST-UPDATED    "201312130000Z"     -- 13 December 2013=20
        =20
     =20
     =20
               Expires June 13, 2014          [Page 28]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            ORGANIZATION    "IETF EMAN Working Group"=20
            CONTACT-INFO=20
                    "WG charter:=20
                    http://datatracker.ietf.org/wg/eman/charter/=20
        =20
                  Mailing Lists:=20
                     General Discussion: eman@ietf.org=20

                     To Subscribe: =20
                     https://www.ietf.org/mailman/listinfo/eman=20

                     Archive: =20
                     http://www.ietf.org/mail-archive/web/eman=20

                  Editors:=20
                     Mouli Chandramouli=20
                     Cisco Systems, Inc.=20
                     Sarjapur Outer Ring Road=20
                     Bangalore 560103=20
                     IN=20
                     Phone: +91 80 4429 2409 =20
                     Email: moulchan@cisco.com=20

                     Benoit Claise=20
                     Cisco Systems, Inc.=20
                     De Kleetlaan 6a b1=20
                     Degem 1831=20
                     Belgium=20
                     Phone:  +32 2 704 5622=20
                     Email: bclaise@cisco.com=20

                     Brad Schoening=20
                     44 Rivers Edge Drive=20
                     Little Silver, NJ 07739=20
                     US=20
                     Email: brad.schoening@verizon.net=20

                     Juergen Quittek=20
                     NEC Europe Ltd.=20
                     NEC Laboratories Europe=20
                     Network Research Division=20
                     Kurfuersten-Anlage 36=20
                     Heidelberg  69115=20
                     DE=20
                     Phone: +49 6221 4342-115=20
                     Email: quittek@neclab.eu=20


     =20
     =20
               Expires June 13, 2014          [Page 29]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                     Thomas Dietz=20
                     NEC Europe Ltd.=20
                     NEC Laboratories Europe=20
                     Network Research Division=20
                     Kurfuersten-Anlage 36=20
                     69115 Heidelberg=20
                     DE=20
                     Phone: +49 6221 4342-128=20
                     Email: Thomas.Dietz@nw.neclab.eu"=20

            DESCRIPTION=20
               "This MIB is used to monitor power and energy in =20
                devices. =20
        =20
                This table sparse extension of the eoTable =20
                from the ENERGY-OBJECT-CONTEXT-MIB. As a requirement =20
                [EMAN-AWARE-MIB] must be implemented.=20
                 =20
                 =20
                 Module Compliance of ENTITY-MIB v4=20
                 with respect to entity4CRCompliance should =20
                 be supported which requires implementation =20
                 of 3 MIB objects (entPhysicalIndex, =20
                 entPhysicalName and entPhysicalUUID)."=20
        =20
            REVISION=20
                  "201312130000Z"     -- 13 December 2013 =20
        =20
            DESCRIPTION=20
               "Initial version, published as RFC YYY."=20
        =20
           ::=3D { energyMIB 3 }=20
        =20
        =20
        energyObjectMIBNotifs OBJECT IDENTIFIER=20
            ::=3D { energyObjectMIB 0 }=20
        =20
        energyObjectMIBObjects OBJECT IDENTIFIER=20
            ::=3D { energyObjectMIB 1 }=20
     =20
        energyObjectMIBConform  OBJECT IDENTIFIER=20
            ::=3D { energyObjectMIB 2 }=20
        =20
                                   =20
        -- Textual Conventions=20
     =20
        =20
        UnitMultiplier ::=3D TEXTUAL-CONVENTION=20
     =20
     =20
               Expires June 13, 2014          [Page 30]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            STATUS          current=20
            DESCRIPTION =20
               "The Unit Multiplier is an integer value that represents=20=

               the IEEE 61850 Annex A units multiplier associated with=20=

               the integer units used to measure the power or energy. =20=

                =20
               For example, when used with eoPowerUnitMultiplier, -3=20
               represents 10^-3 or milliwatts."=20
            REFERENCE=20
                    "The International System of Units (SI),=20
                    National Institute of Standards and Technology,=20
                    Spec. Publ. 330, August 1991."=20
            SYNTAX INTEGER {=20
                yocto(-24),   -- 10^-24=20
                zepto(-21),   -- 10^-21=20
                atto(-18),    -- 10^-18=20
                femto(-15),   -- 10^-15=20
                pico(-12),    -- 10^-12=20
                nano(-9),     -- 10^-9=20
                micro(-6),    -- 10^-6=20
                milli(-3),    -- 10^-3=20
                units(0),     -- 10^0=20
                kilo(3),      -- 10^3=20
                mega(6),      -- 10^6=20
                giga(9),      -- 10^9=20
                tera(12),     -- 10^12=20
                peta(15),     -- 10^15=20
                exa(18),      -- 10^18=20
                zetta(21),    -- 10^21=20
                yotta(24)     -- 10^24=20
            }=20
         =20
        -- Objects=20
        =20
     =20
     =20
        eoMeterCapabilitiesTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoMeterCapabilitiesEntry =20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
        "This table is useful for helping applications determine the=20
        monitoring capabilities supported by the local management=20
        agents.  It is possible for applications to know which tables =20=

        are usable without going through a trial-and-error process."=20
            ::=3D { energyObjectMIBObjects 1 }=20
        =20
        =20
     =20
     =20
               Expires June 13, 2014          [Page 31]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        eoMeterCapabilitiesEntry OBJECT-TYPE=20
            SYNTAX          EoMeterCapabilitiesEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
        "An entry describes the metering capability of an Energy=20
        Object."=20
            INDEX        { entPhysicalIndex }    =20
        ::=3D { eoMeterCapabilitiesTable  1 }=20
        =20
     =20
        EoMeterCapabilitiesEntry ::=3D SEQUENCE {=20
                  eoMeterCapability          BITS=20
                       }=20
        =20
        eoMeterCapability OBJECT-TYPE=20
                   SYNTAX   BITS {=20
                      none(0), =20
                      powermetering(1),        -- power measurement =20
                      energymetering(2),       -- energy measurement=20
                      powerattributes(3)  -- power attributes    =20
                            }=20
                   MAX-ACCESS      read-only=20
                   STATUS          current=20
                   DESCRIPTION =20
        "An indication of the Energy monitoring capabilities supported=20=

        by this agent. This object use a BITS syntax  and indicate the=20=

        MIB groups supported by the probe. By reading the value of this=20=

        object, it is possible to determine the MIB tables supported. "=20=

            ::=3D { eoMeterCapabilitiesEntry 1  }=20
        =20
        =20
        eoPowerTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoPowerEntry =20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "This table lists Energy Objects."=20
            ::=3D { energyObjectMIBObjects 2  }=20
        =20
        =20
        eoPowerEntry OBJECT-TYPE=20
            SYNTAX          EoPowerEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "An entry describes the power usage of an Energy Object."=20=

        =20
     =20
     =20
               Expires June 13, 2014          [Page 32]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            INDEX        { entPhysicalIndex }    =20
        ::=3D { eoPowerTable  1 }=20
        =20
        =20
        EoPowerEntry ::=3D SEQUENCE {=20
                   =20
                eoPower                         Integer32,=20
                eoPowerNameplate                Integer32,=20
                eoPowerUnitMultiplier           UnitMultiplier,=20
                eoPowerAccuracy                 Integer32,               =
   =20
                eoPowerMeasurementCaliber       INTEGER,=20
                eoPowerCurrentType              INTEGER,=20
                eoPowerOrigin                   INTEGER,=20
                eoPowerAdminState               IANAPowerStateSet, =20
                eoPowerOperState                IANAPowerStateSet, =20
                eoPowerStateEnterReason         OwnerString=20
          }=20
        =20
        =20
        =20
        eoPower OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only? You can't have negative =
watts can you?

            UNITS           "Watts"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object indicates the power measured for the Energy=20=

               Object. For alternating current, this value is obtained=20=

               as an average over fixed number of AC cycles.  .  This=20
               value is specified in SI units of watts with the=20
               magnitude of watts (milliwatts, kilowatts, etc.)=20
               indicated separately in eoPowerUnitMultiplier. The=20
               accuracy of the measurement is specfied in=20
               eoPowerAccuracy. The direction of power flow is indicated=20=

               by the sign on eoPower. If the Energy Object is consuming=20=

               power, the eoPower value will be positive. If the Energy=20=

               Object is producing power, the eoPower value will be=20
               negative.  =20
          =20
               The eoPower MUST be less than or equal to the maximum=20
               power that can be consumed at the power state specified=20=

               by eoPowerState.=20
          =20
               The eoPowerMeasurementCaliber object specifies how the=20
               usage value reported by eoPower was obtained. The eoPower=20=

               value must report 0 if the eoPowerMeasurementCaliber is=20=

               'unavailable'.  For devices that can not measure or=20
               report power, this option can be used." =20
     =20
     =20
               Expires June 13, 2014          [Page 33]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            ::=3D { eoPowerEntry 1  }=20
        =20
        =20
        eoPowerNameplate OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           "Watts"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object indicates the rated maximum consumption for=20=

               the fully populated Energy Object.  The nameplate power=20=

               requirements are the maximum power numbers and, in almost=20=


TOM: "maximum power numbers given in Watts..."

               all cases, are well above the expected operational=20
               consumption.  The eoPowerNameplate is widely used for=20
               power provisioning.  This value is specified in either=20
               units of watts or voltage and current.  The units are=20
               therefore SI watts or equivalent Volt-Amperes with the=20
               magnitude (milliwatts, kilowatts, etc.) indicated=20
TOM: So here you say "SI watts" so should the UNITS above be "SI Watts"?

               separately in eoPowerUnitMultiplier." =20
            ::=3D { eoPowerEntry 2  }=20
        =20
        eoPowerUnitMultiplier OBJECT-TYPE=20
            SYNTAX          UnitMultiplier=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "The magnitude of watts for the usage value in eoPower=20
               and eoPowerNameplate." =20
            ::=3D { eoPowerEntry 3  }=20
        =20
        eoPowerAccuracy OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object indicates a percentage value, in 100ths of a=20=

               percent, representing the assumed accuracy of the usage=20=

               reported by eoPower. For example: The value 1010 means=20
               the reported usage is accurate to +/- 10.1 percent.  This=20=

               value is zero if the accuracy is unknown or not=20
               applicable based upon the measurement method.=20
               =20
               ANSI and IEC define the following accuracy classes for=20
               power measurement:=20
                    IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.=20
                    ANSI C12.20 class 0.2, 0.5"=20
            ::=3D { eoPowerEntry 4  }=20
     =20
     =20
               Expires June 13, 2014          [Page 34]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
        =20
        eoPowerMeasurementCaliber   OBJECT-TYPE=20
            SYNTAX          INTEGER  {=20
                                unavailable(1) ,         =20
                                unknown(2), =20
                                actual(3) ,=20
                                estimated(4),  =20
                                static(5)                    }=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object specifies how the usage value reported by=20
               eoPower was obtained:=20
               =20
               - unavailable(1): Indicates that the usage is not=20
               available. In such a case, the eoPower value must be 0=20
               for devices that can not measure or report power this=20
               option can be used.=20
               =20
               - unknown(2): Indicates that the way the usage was=20
               determined is unknown. In some cases, entities report=20
               aggregate power on behalf of another device. In such=20
               cases it is not known whether the usage reported is=20
               actual(2), estimated(3) or presumed (4).=20
                =20
               - actual(3):  Indicates that the reported usage was=20
               measured by the entity through some hardware or direct=20
               physical means. The usage data reported is not presumed=20=

               (4) or estimated (3) but is the measured consumption=20
               rate. =20

               - estimated(4): Indicates that the usage was not=20
               determined by physical measurement. The value is a=20
               derivation based upon the device type, state, and/or=20
               current utilization using some algorithm or heuristic. It=20=

               is presumed that the entity's state and current=20
               configuration were used to compute the value.  =20
              =20
              - static(5): Indicates that the usage was not determined=20=

              by physical measurement, algorithm or derivation. The=20
              usage was reported based upon external tables,=20
              specifications, and/or model information.  For example, a=20=

              PC Model X draws 200W, while a PC Model Y draws 210W"=20
              =20
         ::=3D { eoPowerEntry 5  }=20
     =20
        eoPowerCurrentType OBJECT-TYPE=20
     =20
     =20
               Expires June 13, 2014          [Page 35]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
              SYNTAX      INTEGER  {=20
                               ac(1),=20
                               dc(2),=20
                               unknown(3)=20
                           }=20
               MAX-ACCESS  read-only=20
               STATUS      current=20
            DESCRIPTION=20
               "This object indicates whether the eoPower for the =20
               Energy Object reports alternating current AC(1), direct=20=

               current DC(2), or that the current type is unknown(3)." =20=

         ::=3D { eoPowerEntry 6  }=20
     =20
        eoPowerOrigin  OBJECT-TYPE=20
            SYNTAX          INTEGER  {=20
                                self (1), =20
                                remote (2)                    =20
                            }=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object indicates the source of power measurement=20
               and can be useful when modeling the power usage of=20
               attached devices. The power measurement can be performed=20=

               by the entity itself or the power measurement of the=20
               entity can be reported by another trusted entity using a=20=

               protocol extension.  A value of self(1) indicates the=20
               measurement is performed by the entity, whereas remote(2)=20=

               indicates that the measurement was performed by another=20=

               entity." =20
            ::=3D { eoPowerEntry 7  }=20
        =20
        eoPowerAdminState OBJECT-TYPE=20
            SYNTAX          IANAPowerStateSet =20
            MAX-ACCESS      read-write=20
            STATUS          current=20
            DESCRIPTION=20
                "This object specifies the desired Power State and the=20=

                Power State Set for the Energy Object. Note that=20
                other(0) is not a Power State Set and unknown(255) is=20
                not a Power State as such, but simply an indication that=20=

                the Power State of the Energy Object is unknown.=20
                Possible values of eoPowerAdminState within the Power=20
                State Set are registered at IANA.  =20
                A current list of assignments can be found at=20
                =20
                RFC-EDITOR: please check the location after IANA"=20
            ::=3D { eoPowerEntry 8  }=20
     =20
     =20
               Expires June 13, 2014          [Page 36]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
          =20
        eoPowerOperState OBJECT-TYPE=20
            SYNTAX          IANAPowerStateSet =20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                =20
                =20
                "This object specifies the current operational Power=20
                State and the Power State Set for the Energy Object.=20
                other(0) is not a Power State Set and unknown(255) is=20
                not a Power State as such, but simply an indication that=20=

                the Power State of the Energy Object is unknown.=20
                =20
                Possible values of eoPowerAdminState within the Power=20
                State Set are registered at IANA.  =20
                A current list of assignments can be found at=20
                =20
                RFC-EDITOR: please check the location after IANA"=20
                =20
            ::=3D { eoPowerEntry 9    }=20
     =20
        eoPowerStateEnterReason OBJECT-TYPE=20
             SYNTAX     OwnerString=20
             MAX-ACCESS read-write=20
             STATUS     current=20
             DESCRIPTION=20
                "This string object describes the reason for the=20
                eoPowerAdminState =20
                transition Alternatively, this string may contain with=20=

                the entity that configured this Energy Object to this=20
                Power State." =20
             DEFVAL { "" }=20
             ::=3D { eoPowerEntry 10   }=20
     =20
        eoPowerStateTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoPowerStateEntry =20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "This table enumerates the maximum power usage, in watts,=20=

               for every single supported Power State of each Energy=20
               Object.=20
               =20
               This table has an expansion-dependent relationship on the=20=

               eoPowerTable, containing rows describing each Power State=20=

               for the corresponding Energy Object. For every Energy=20

     =20
     =20
               Expires June 13, 2014          [Page 37]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
               Object in the eoPowerTable, there is a corresponding=20
               entry in this table."=20
            ::=3D { energyObjectMIBObjects 3  }=20
     =20
        eoPowerStateEntry OBJECT-TYPE=20
            SYNTAX          EoPowerStateEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "A eoPowerStateEntry extends a corresponding=20
               eoPowerEntry.  This entry displays max usage values at=20
               every single possible Power State supported by the Energy=20=

               Object. =20
               For example, given the values of a Energy Object =20
               corresponding to a maximum usage of 0 W at the =20
               state 1 (mechoff), 8 W at state 6 (ready), 11 W at state=20=

               9 (mediumMinus),and 11 W at state 12 (high):=20
               =20
                    State         MaxUsage Units=20
                     1 (mechoff       0       W           =20
                     2 (softoff)      0       W           =20
                     3 (hibernate)    0       W           =20
                     4 (sleep)        0       W           =20
                     5 (standby)      0       W           =20
                     6 (ready)        8       W          =20
                     7 (lowMinus)     8       W          =20
                     8 (low)         11       W  =20
                     9 (mediumMinus) 11       W=20
                    10 (medium)      11       W   =20
                    11 (highMinus)   11       W=20
                    12 (high)        11       W                =20
               =20
               Furthermore, this table extends to return the total time=20=

               in each Power State, along with the number of times a=20
               particular Power State was entered."=20
               =20
                        INDEX   { entPhysicalIndex,                      =
          =20
                                  eoPowerStateIndex                   =20=

                                } =20
            ::=3D { eoPowerStateTable 1 }=20
        =20
        EoPowerStateEntry ::=3D SEQUENCE {=20
                eoPowerStateIndex                 IANAPowerStateSet, =20
                eoPowerStateMaxPower              Integer32,=20
                eoPowerStatePowerUnitMultiplier   UnitMultiplier,       =20=

                eoPowerStateTotalTime             TimeTicks,=20
                eoPowerStateEnterCount            Counter32=20
        }=20

TOM: Should this table have a StorageType object to indicate volitility =
state?
     =20
     =20
               Expires June 13, 2014          [Page 38]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
        eoPowerStateIndex OBJECT-TYPE    =20
            SYNTAX          IANAPowerStateSet     =20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
                " =20
                This object specifies the index of the Power State of=20
                the Energy Object within a Power State Set. The=20
                semantics of the specific Power State can be obtained=20
                from the Power State Set definition."=20
            ::=3D { eoPowerStateEntry 1 }=20
     =20
     =20
        eoPowerStateMaxPower OBJECT-TYPE=20
            SYNTAX          Integer32=20
            UNITS           "Watts"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object indicates the maximum power for the Energy=20=

               Object at the particular Power State. This value is=20
               specified in SI units of watts with the magnitude of the=20=

               units (milliwatts, kilowatts, etc.) indicated separately=20=

               in eoPowerStatePowerUnitMultiplier. If the maximum power=20=

               is not known for a certain Power State, then the value is=20=

               encoded as 0xFFFF.=20
               =20
               For Power States not enumerated, the value of=20
               eoPowerStateMaxPower might be interpolated by using the=20=

               next highest supported Power State." =20
            ::=3D { eoPowerStateEntry 2  }=20
        =20
        eoPowerStatePowerUnitMultiplier OBJECT-TYPE=20
            SYNTAX          UnitMultiplier =20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "The magnitude of watts for the usage value in=20
               eoPowerStateMaxPower." =20
            ::=3D { eoPowerStateEntry 3  }=20
        =20
        eoPowerStateTotalTime OBJECT-TYPE=20
            SYNTAX      TimeTicks=20
            MAX-ACCESS  read-only=20
            STATUS      current=20
            DESCRIPTION=20
              "This object indicates the total time in hundredth=20
     =20
     =20
               Expires June 13, 2014          [Page 39]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
              of second that the Energy Object has been in this power=20
              state since the last reset, as specified in the=20
              sysUpTime."=20
            ::=3D { eoPowerStateEntry 4  }=20
        =20
        eoPowerStateEnterCount OBJECT-TYPE=20
            SYNTAX       Counter32=20
            MAX-ACCESS   read-only=20
            STATUS       current=20
            DESCRIPTION=20
               "This object indicates how often the Energy =20
                Object has=20
                entered this power state, since the last reset of the=20
                device as specified in the sysUpTime."=20
            ::=3D { eoPowerStateEntry 5   }=20
     =20
     =20
        eoEnergyParametersTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoEnergyParametersEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
              "This table is used to configure the parameters for=20
              Energy measurement collection in the table =20
              eoEnergyTable. This table allows the configuration of=20
              different measurement settings on the same Energy Object.=20=

              Implementation of this table only sense for Energy=20
              Objects that an eoPowerMeasurementCaliber of actual(3)."   =
 =20
               ::=3D { energyObjectMIBObjects 4   }=20

        eoEnergyParametersEntry OBJECT-TYPE=20
            SYNTAX          EoEnergyParametersEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "An entry controls an energy measurement in=20
               eoEnergyTable."=20
            INDEX  { eoEnergyObjectIndex, eoEnergyParametersIndex } =20
            ::=3D { eoEnergyParametersTable 1 }=20
        =20
        EoEnergyParametersEntry ::=3D SEQUENCE {=20
                eoEnergyObjectIndex                PhysicalIndex,=20
                eoEnergyParametersIndex            Integer32,=20
                eoEnergyParametersIntervalLength   TimeInterval,=20
                eoEnergyParametersIntervalNumber   Integer32,=20
                eoEnergyParametersIntervalMode     INTEGER,=20
                eoEnergyParametersIntervalWindow   TimeInterval,=20
                eoEnergyParametersSampleRate       Integer32,=20
     =20
     =20
               Expires June 13, 2014          [Page 40]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                eoEnergyParametersStatus           RowStatus=20
        }=20
        =20
        eoEnergyObjectIndex OBJECT-TYPE=20
            SYNTAX          PhysicalIndex=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
              "The unique value, to identify the specific Energy Object=20=

              on which the measurement is applied, the same index used=20=

              in the eoPowerTable to identify the Energy Object."=20
            ::=3D { eoEnergyParametersEntry 1 }=20
        =20
        eoEnergyParametersIndex OBJECT-TYPE    =20
            SYNTAX           Integer32 (0..2147483647)   =20
            MAX-ACCESS       read-create=20

TOM: This value should not be accessible as it is an index. Its =
max-access should be "not-accessible".

            STATUS           current=20
            DESCRIPTION=20
                "This object specifies the index of the Energy=20
                Parameters setting for collection of energy measurements=20=

                for an Energy Object. An Energy Object can have multiple=20=

                eoEnergyParametersIndex, depending on the capability of=20=

                the Energy Object"=20
            ::=3D { eoEnergyParametersEntry 2 }=20

TOM: Is the value of 0 as the index representative of some special state =
or value?  Generally we do not allow 0 as a value unless there is a good =
reason for this.=20
        =20
        eoEnergyParametersIntervalLength OBJECT-TYPE=20
            SYNTAX          TimeInterval=20
            MAX-ACCESS      read-create=20
            STATUS          current=20
            DESCRIPTION=20
               "This object indicates the length of time in hundredth of=20=

               seconds over which to compute the average=20
               eoEnergyConsumed  measurement in the eoEnergyTable table.=20=

               The computation is based on the Energy Object's internal=20=

               sampling rate of power consumed or produced by the Energy=20=

               Object. The sampling rate is the rate at which the Energy=20=

               Object can read the power usage and may differ based on=20=

               device capabilities. The average energy consumption is=20
               then computed over the length of the interval." =20
            DEFVAL { 90000 }=20
            ::=3D { eoEnergyParametersEntry 3 }=20
        =20
        eoEnergyParametersIntervalNumber OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            MAX-ACCESS      read-create=20
            STATUS          current=20
            DESCRIPTION=20
     =20
     =20
               Expires June 13, 2014          [Page 41]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                              =20
               "The number of intervals maintained in the eoEnergyTable.=20=

               Each interval is characterized by a specific=20
               eoEnergyCollectionStartTime, used as an index to the=20
               table eoEnergyTable. Whenever the maximum number of=20
               entries is reached, the measurement over the new interval=20=

               replaces the oldest measurement. There is one exception=20=

               to this rule: when the eoEnergyMaxConsumed and/or=20
               eoEnergyMaxProduced are in (one of) the two oldest=20
               measurement(s), they are left untouched and the next=20
               oldest measurement is replaced."        =20
               DEFVAL { 10 } =20
          ::=3D { eoEnergyParametersEntry 4 }=20
        =20
        eoEnergyParametersIntervalMode OBJECT-TYPE=20
          SYNTAX          INTEGER  {=20
                              period(1),=20
                              sliding(2),=20
                              total(3)=20
                          }=20
          MAX-ACCESS      read-create=20
          STATUS          current=20
          DESCRIPTION=20
            "A control object to define the mode of interval calculation=20=

            for the computation of the average eoEnergyConsumed or=20
            eoEnergyProvided  measurement in the eoEnergyTable table.   =20=

              =20
              A mode of period(1) specifies non-overlapping periodic=20
              measurements.=20
            =20
              A mode of sliding(2) specifies overlapping sliding windows=20=

              where the interval between the start of one interval and=20=

              the next is defined in eoEnergyParametersIntervalWindow.=20=

            =20
              A mode of total(3) specifies non-periodic measurement.  In=20=

              this mode only one interval is used as this is a=20
              continuous measurement since the last reset. The value of=20=

              eoEnergyParametersIntervalNumber should be (1) one and=20
              eoEnergyParametersIntervalLength is ignored. " =20
           ::=3D { eoEnergyParametersEntry 5 }=20
        =20
        eoEnergyParametersIntervalWindow OBJECT-TYPE=20
          SYNTAX          TimeInterval=20
          MAX-ACCESS      read-create=20
          STATUS          current=20
          DESCRIPTION=20
             "The length of the duration window between the starting=20
             time of one sliding window and the next starting time in=20
     =20
     =20
               Expires June 13, 2014          [Page 42]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
             hundredth of seconds, in order to compute the average of=20
             eoEnergyConsumed, eoEnergyProvided measurements in the=20
             eoEnergyTable table. This is valid only when the=20
             eoEnergyParametersIntervalMode is sliding(2). The=20
             eoEnergyParametersIntervalWindow value should be a multiple=20=

             of eoEnergyParametersSampleRate."=20
               ::=3D { eoEnergyParametersEntry 6 }=20
        =20
        eoEnergyParametersSampleRate OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           "Milliseconds"=20
            MAX-ACCESS      read-create=20
            STATUS          current=20
            DESCRIPTION=20
               "The sampling rate, in milliseconds, at which the  Energy=20=

               Object should poll power usage in order to compute the=20
               average eoEnergyConsumed, eoEnergyProvided  measurements=20=

               in the table eoEnergyTable.  The Energy Object should=20
               initially set this sampling rate to a reasonable value,=20=

               i.e., a compromise between intervals that will provide=20
               good accuracy by not being too long, but not so short=20
               that they affect the Energy Object performance by=20
               requesting continuous polling. If the sampling rate is=20
               unknown, the value 0 is reported. The sampling rate=20
               should be selected so that=20
               eoEnergyParametersIntervalWindow is a multiple of=20
               eoEnergyParametersSampleRate."=20
             DEFVAL { 1000 } =20
            ::=3D { eoEnergyParametersEntry 7 }=20
        =20
        eoEnergyParametersStatus OBJECT-TYPE=20
            SYNTAX          RowStatus=20
            MAX-ACCESS      read-create=20
            STATUS          current=20
            DESCRIPTION=20
              "The status of this row. The eoEnergyParametersStatus is=20=

              used to start or stop energy usage logging. An entry=20
              status may not be active(1) unless all objects in the=20
              entry have an appropriate value.  If this object is not=20
              equal to active(1), all associated usage-data logged into=20=

              the eoEnergyTable will be deleted. The data can be=20
              destroyed by setting up the eoEnergyParametersStatus to=20
              destroy(2)."=20
            ::=3D {eoEnergyParametersEntry 8 }=20
     =20
        eoEnergyTable OBJECT-TYPE=20

     =20
     =20
               Expires June 13, 2014          [Page 43]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            SYNTAX          SEQUENCE OF EoEnergyEntry =20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "This table lists Energy Object energy measurements. =20
               Entries in this table are only created if the=20
               corresponding value of object eoPowerMeasurementCaliber=20=

               is active(3), i.e., if the power is actually metered."=20
            ::=3D { energyObjectMIBObjects 5   }=20
        =20
        eoEnergyEntry OBJECT-TYPE=20
            SYNTAX          EoEnergyEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
                "An entry describing energy measurements."=20
            INDEX  { eoEnergyParametersIndex,      =20
        eoEnergyCollectionStartTime }=20
            ::=3D { eoEnergyTable 1 }=20

        EoEnergyEntry ::=3D SEQUENCE {=20
             eoEnergyCollectionStartTime       TimeTicks,=20
             eoEnergyConsumed                  Integer32,  =20
             eoEnergyProvided                  Integer32, =20
             eoEnergyStored                    Integer32,=20
             eoEnergyUnitMultiplier            UnitMultiplier,=20
             eoEnergyAccuracy                  Integer32,=20
             eoEnergyMaxConsumed               Integer32,=20
             eoEnergyMaxProduced               Integer32,=20
             eoEnergyDiscontinuityTime         TimeStamp =20
        }=20
        =20
        eoEnergyCollectionStartTime OBJECT-TYPE=20
            SYNTAX          TimeTicks=20
            UNITS           "hundredths of seconds"=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "The time (in hundredths of a second) since the=20
               network management portion of the system was last=20
               re-initialized, as specified in the sysUpTime [RFC3418].=20=

               This object specifies the start time of the energy=20
               measurement sample. " =20
            ::=3D { eoEnergyEntry 1 }=20
     =20
        eoEnergyConsumed OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?
     =20
               Expires June 13, 2014          [Page 44]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            UNITS           "Watt-hours"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
        "This object indicates the energy consumed in units of watt-
        hours for the Energy Object over the defined interval. =20
        This value is specified in the common billing units of watt-
        hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) =20
        indicated separately in eoEnergyUnitMultiplier." =20
            ::=3D { eoEnergyEntry 2 }=20
        =20
        =20
        eoEnergyProvided OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           "Watt-hours"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
        "This object indicates the energy produced in units of watt-
        hours for the Energy Object over the defined interval. =20
        This value is specified in the common billing units of watt-
        hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) =20
        indicated separately in eoEnergyUnitMultiplier." =20
            ::=3D { eoEnergyEntry 3 }=20
        =20
        eoEnergyStored OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           "Watt-hours"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
        "This object indicates the resultant of the energy consumed and=20=

        energy produced for an Energy Object in units of watt-hours for =20=

        the Energy Object over the defined interval. This value is=20
        specified in the common billing units of watt-hours =20
        with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) =20
        indicated separately in eoEnergyUnitMultiplier." =20
            ::=3D { eoEnergyEntry 4 }=20
        =20
        eoEnergyUnitMultiplier OBJECT-TYPE=20
            SYNTAX          UnitMultiplier=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object is the magnitude of watt-hours for the=20
               energy field in eoEnergyConsumed, eoEnergyProvided,=20
               eoEnergyStored, eoEnergyMaxConsumed, and=20
               eoEnergyMaxProduced ." =20
     =20
     =20
               Expires June 13, 2014          [Page 45]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            ::=3D { eoEnergyEntry 5  }=20
        =20
        =20
        =20
        eoEnergyAccuracy OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
        "This object indicates a percentage value, in 100ths of a=20
        percent, representing the presumed accuracy of Energy usage=20
        reporting. eoEnergyAccuracy is applicable to all Energy=20
        measurements in the  eoEnergyTable.=20
        =20
        For example: 1010 means the reported usage is accurate to +/-=20
        10.1 percent.=20
        This value is zero if the accuracy is unknown."=20
        =20
            ::=3D { eoEnergyEntry 6 }=20
        =20
        eoEnergyMaxConsumed OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           "Watt-hours"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object is the maximum energy ever observed in=20
               eoEnergyConsumed since the monitoring started. This value=20=

               is specified in the common billing units of watt-hours=20
               with the magnitude of watt-hours (kW-Hr,   MW-Hr, etc.)=20=

               indicated separately in eoEnergyUnitMultiplier." =20
            ::=3D { eoEnergyEntry 7  }=20
        =20
        =20
        eoEnergyMaxProduced OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be a positive number only?

            UNITS           "Watt-hours"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object is the maximum energy ever observed in=20
               eoEnergyEnergyProduced since the monitoring started. This=20=

               value is specified in the units of watt-hours with the=20
               magnitude of watt-hours (kW-Hr,   MW-Hr, etc.) indicated=20=

               separately in eoEnergyEnergyUnitMultiplier." =20
            ::=3D { eoEnergyEntry 8 }=20
     =20
     =20
     =20
               Expires June 13, 2014          [Page 46]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
         eoEnergyDiscontinuityTime OBJECT-TYPE=20
            SYNTAX       TimeStamp=20
            MAX-ACCESS  read-only=20
            STATUS      current=20
            DESCRIPTION=20
              =20
              "The value of sysUpTime [RFC3418] on the most recent=20
              occasion at which any one or more of this entity's energy=20=

              counters in this table suffered a discontinuity: =20
              eoEnergyConsumed, eoEnergyProvided or eoEnergyStored. If=20=

              no such discontinuities have occurred since the last re-
              initialization of the local management subsystem, then=20
              this object contains a zero value."=20
            ::=3D { eoEnergyEntry 9 }=20
        =20
        -- Notifications=20
        =20
        =20
        eoPowerEnableStatusNotification OBJECT-TYPE=20
            SYNTAX          TruthValue=20
            MAX-ACCESS      read-write=20
            STATUS          current=20
            DESCRIPTION        "This variable indicates whether the =20
            system produces the following notifications:=20

TOM: notifications -> notification  as there is only one.

             eoPowerStateChange.=20
        =20
                A false value will prevent these notifications=20
                from being generated."=20
            DEFVAL          { false } =20
            ::=3D { energyObjectMIBNotifs 1 }=20
     =20
        =20
        eoPowerStateChange NOTIFICATION-TYPE=20
            OBJECTS       {eoPowerAdminState, eoPowerOperState,=20
        eoPowerStateEnterReason}=20
            STATUS        current=20
            DESCRIPTION=20
                "The SNMP entity generates the eoPowerStateChange when=20=

                the value(s) of eoPowerAdminState or eoPowerOperState, =20=

                in the context of the Power State Set, have changed for=20=

                the Energy Object represented by the entPhysicalIndex."=20=

           ::=3D { energyObjectMIBNotifs 2 }=20
        =20
        -- Conformance=20
        =20
        energyObjectMIBCompliances  OBJECT IDENTIFIER=20
            ::=3D { energyObjectMIBConform 1 }=20
     =20
     =20
               Expires June 13, 2014          [Page 47]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
        energyObjectMIBGroups  OBJECT IDENTIFIER=20
            ::=3D { energyObjectMIBConform 2 }=20
        =20
        =20
        energyObjectMIBFullCompliance MODULE-COMPLIANCE=20
            STATUS          current=20
            DESCRIPTION=20
                "When this MIB is implemented with support for=20
                read-create, then such an implementation can =20
                claim full compliance. Such devices can then =20
                be both monitored and configured with this MIB.=20
                 =20
                Module Compliance of [RFC6933]=20
                with respect to entity4CRCompliance should =20
                be supported which requires implementation =20
                of 3 MIB objects (entPhysicalIndex, =20
                entPhysicalName and entPhysicalUUID)."=20
        =20
            MODULE          -- this module=20
            MANDATORY-GROUPS {=20
                        energyObjectMIBTableGroup,=20
                        energyObjectMIBStateTableGroup,=20
                        eoPowerEnableStatusNotificationGroup,=20
                        energyObjectMIBNotifGroup=20
                            }=20
        =20
              GROUP     energyObjectMIBEnergyTableGroup =20
        =20
                  DESCRIPTION "A compliant implementation does not =20
                  have to implement.  =20
        =20
                  Module Compliance of [RFC6933] =20
                  with respect to entity4CRCompliance should =20
                  be supported which requires implementation =20
                  of 3 MIB objects (entPhysicalIndex, =20
                  entPhysicalName and entPhysicalUUID)."=20
        =20
        =20
              GROUP    energyObjectMIBEnergyParametersTableGroup=20
        =20
                  DESCRIPTION "A compliant implementation does not =20
                  have to implement. =20
        =20
                  Module Compliance of {RFC6933] =20
                  with respect to entity4CRCompliance should =20
                  be supported which requires implementation =20
                  of 3 MIB objects (entPhysicalIndex, =20
     =20
     =20
               Expires June 13, 2014          [Page 48]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                  entPhysicalName and entPhysicalUUID)."=20
         =20
        =20
             GROUP     energyObjectMIBMeterCapabilitiesTableGroup =20
        =20
                  DESCRIPTION "A compliant implementation does not =20
                  have to implement. =20
        =20
                  Module Compliance of [RFC6933] =20
                  with respect to entity4CRCompliance should =20
                  be supported which requires implementation =20
                  of 3 MIB objects (entPhysicalIndex, =20
                  entPhysicalName and entPhysicalUUID)."=20
        =20
     =20
            ::=3D { energyObjectMIBCompliances 1 }=20
        =20
        energyObjectMIBReadOnlyCompliance MODULE-COMPLIANCE=20
            STATUS          current=20
            DESCRIPTION=20
                "When this MIB is implemented without support for=20
                read-create (i.e. in read-only mode), then such an =20
                implementation can claim read-only compliance.  Such a =20=

                device can then be monitored but cannot be =20
                configured with this MIB. =20
        =20
                Module Compliance of [RFC6933] =20
                with respect to entity4CRCompliance should =20
                be supported which requires implementation =20
                of 3 MIB objects (entPhysicalIndex, =20
                entPhysicalName and entPhysicalUUID)."=20
        =20
            MODULE          -- this module=20
            MANDATORY-GROUPS {=20
                                energyObjectMIBTableGroup,=20
                                energyObjectMIBStateTableGroup,  =20
                                energyObjectMIBNotifGroup=20
                            }=20
        =20
            OBJECT          eoPowerOperState=20
            MIN-ACCESS      read-only=20
            DESCRIPTION=20
                "Write access is not required." =20
            ::=3D { energyObjectMIBCompliances 2 }=20
        =20
        -- Units of Conformance=20
        =20
        energyObjectMIBTableGroup OBJECT-GROUP=20
     =20
     =20
               Expires June 13, 2014          [Page 49]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            OBJECTS         {=20
                                eoPower,=20
                                eoPowerNameplate,=20
                                eoPowerUnitMultiplier,=20
                                eoPowerAccuracy,                        =20=

                                eoPowerMeasurementCaliber,=20
                                eoPowerCurrentType,=20
                                eoPowerOrigin,=20
                                eoPowerAdminState,=20
                                eoPowerOperState, =20
                                eoPowerStateEnterReason                  =
           =20
                            }              =20
                    STATUS          current=20
            DESCRIPTION=20
                "This group contains the collection of all the objects=20=

                related to the Energy Object."=20
            ::=3D { energyObjectMIBGroups 1 }=20
        =20
        energyObjectMIBStateTableGroup OBJECT-GROUP=20
               OBJECTS      {=20
                                 eoPowerStateMaxPower,=20
                                 eoPowerStatePowerUnitMultiplier,=20
                                 eoPowerStateTotalTime,                  =
     =20
                                 eoPowerStateEnterCount           =20
                            }=20
                    STATUS          current=20
                    DESCRIPTION=20
                        "This group contains the collection of all the =20=

                        objects related to the Power State."=20
                    ::=3D { energyObjectMIBGroups 2 }=20
     =20
     =20
        energyObjectMIBEnergyParametersTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                                =20
                                eoEnergyParametersIndex,=20
                                eoEnergyParametersIntervalLength,=20
                                eoEnergyParametersIntervalNumber,=20
                                eoEnergyParametersIntervalMode,=20
                                eoEnergyParametersIntervalWindow,=20
                                eoEnergyParametersSampleRate,=20
                                eoEnergyParametersStatus=20
                            }    =20
            STATUS          current=20
            DESCRIPTION=20
                "This group contains the collection of all the objects=20=

                related to the configuration of the Energy Table."=20

     =20
     =20
               Expires June 13, 2014          [Page 50]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            ::=3D { energyObjectMIBGroups 3 }=20
        =20
     =20
        energyObjectMIBEnergyTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                                -- Note that object =20
                                -- eoEnergyCollectionStartTime is not=20
                                -- included since it is not-accessible=20=

        =20
                                eoEnergyConsumed,=20
                                eoEnergyProvided,=20
                                eoEnergyStored, =20
                                eoEnergyUnitMultiplier,=20
                                eoEnergyAccuracy, =20
                                eoEnergyMaxConsumed,=20
                                eoEnergyMaxProduced,=20
                                eoEnergyDiscontinuityTime  =20
                            }    =20
            STATUS          current=20
            DESCRIPTION=20
                "This group contains the collection of all the objects=20=

                related to the Energy Table."=20
            ::=3D { energyObjectMIBGroups 4 }=20
        =20
        =20
        energyObjectMIBMeterCapabilitiesTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                                 eoMeterCapability  =20
                            }    =20
            STATUS          current=20
            DESCRIPTION=20
                "This group contains the object indicating the=20
        capability of the Energy Object"=20
            ::=3D { energyObjectMIBGroups 5 }=20
        =20
        eoPowerEnableStatusNotificationGroup OBJECT-GROUP=20
            OBJECTS         { eoPowerEnableStatusNotification  }=20
            STATUS          current=20
            DESCRIPTION        "The collection of objects which are used=20=

                                to enable notification."=20
            ::=3D { energyObjectMIBGroups 6 }=20
            =20
        energyObjectMIBNotifGroup NOTIFICATION-GROUP=20
           NOTIFICATIONS    {=20
                                eoPowerStateChange=20
                            }=20
            STATUS          current=20
            DESCRIPTION    "This group contains the notifications for=20
     =20
     =20
               Expires June 13, 2014          [Page 51]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                            the power and energy monitoring MIB Module."=20=

            ::=3D { energyObjectMIBGroups 7 }=20
     =20
        =20
        END=20
        =20
        =20
        =20
        -- ************************************************************=20=

        --   =20
        -- This MIB module is used to monitor power attributes of =20
        --  networked devices with measurements.=20
        --=20
        -- This MIB module is an extension of energyObjectMIB module.=20
        --   =20
        -- *************************************************************=20=

        =20
        =20
        POWER-ATTRIBUTES-MIB DEFINITIONS ::=3D BEGIN=20
        =20
        IMPORTS=20
            MODULE-IDENTITY,=20
            OBJECT-TYPE,=20
            mib-2,=20
            Integer32   =20
               FROM SNMPv2-SMI=20
            MODULE-COMPLIANCE,=20
            OBJECT-GROUP=20
                FROM SNMPv2-CONF=20
            UnitMultiplier =20
                FROM ENERGY-OBJECT-MIB=20
            OwnerString=20
                FROM RMON-MIB=20
            entPhysicalIndex=20
               FROM ENTITY-MIB;   =20
        =20
        powerAttributesMIB MODULE-IDENTITY=20
            =20
            LAST-UPDATED    "201312130000Z"   -- 13 December 2013 =20
        =20
            ORGANIZATION    "IETF EMAN Working Group"=20
            CONTACT-INFO=20
                    "WG charter:=20
                    http://datatracker.ietf.org/wg/eman/charter/=20
        =20
                  Mailing Lists:=20
                     General Discussion: eman@ietf.org=20

     =20
     =20
               Expires June 13, 2014          [Page 52]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                     To Subscribe: =20
                     https://www.ietf.org/mailman/listinfo/eman=20

                     Archive: =20
                     http://www.ietf.org/mail-archive/web/eman=20

                  Editors:=20

                     Mouli Chandramouli=20
                     Cisco Systems, Inc.=20
                     Sarjapur Outer Ring Road=20
                     Bangalore 560103=20
                     IN=20
                     Phone: +91 80 4429 2409 =20
                     Email: moulchan@cisco.com=20

                     Benoit Claise=20
                     Cisco Systems, Inc.=20
                     De Kleetlaan 6a b1=20
                     Degem 1831=20
                     Belgium=20
                     Phone:  +32 2 704 5622=20
                     Email: bclaise@cisco.com=20

                     Brad Schoening=20
                     44 Rivers Edge Drive=20
                     Little Silver, NJ 07739=20
                     US=20
                     Email: brad.schoening@verizon.net=20

                     Juergen Quittek=20
                     NEC Europe Ltd.=20
                     NEC Laboratories Europe=20
                     Network Research Division=20
                     Kurfuersten-Anlage 36=20
                     Heidelberg  69115=20
                     DE=20
                     Phone: +49 6221 4342-115=20
                     Email: quittek@neclab.eu=20

                     Thomas Dietz=20
                     NEC Europe Ltd.=20
                     NEC Laboratories Europe=20
                     Network Research Division=20
                     Kurfuersten-Anlage 36=20
                     69115 Heidelberg=20
                     DE=20

     =20
     =20
               Expires June 13, 2014          [Page 53]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                     Phone: +49 6221 4342-128=20
                     Email: Thomas.Dietz@nw.neclab.eu"=20

            DESCRIPTION=20
                   "This MIB is used to report AC power attributes in=20
                   devices. The table is a sparse augmentation of the=20
                   eoPowerTable table from the energyObjectMIB module.=20=

                   Both three-phase and single-phase power=20
                   configurations are supported. =20
                   =20
                   As a requirement for this MIB module,=20
                   [EMAN-AWARE-MIB] should be implemented. =20
                    =20
                   Module Compliance of ENTITY-MIB v4=20
                   with respect to entity4CRCompliance should =20
                   be supported which requires implementation =20
                   of 3 MIB objects (entPhysicalIndex, =20
                   entPhysicalName and entPhysicalUUID)."=20
        =20
            REVISION=20
     =20
                   "201312130000Z"     -- 13 December 2013=20
     =20
          DESCRIPTION=20
               "Initial version, published as RFC YYY."=20
        =20
           ::=3D { energyMIB 4 }=20
     =20
        =20
        powerAttributesMIBConform  OBJECT IDENTIFIER=20
            ::=3D { powerAttributesMIB 0 }=20
        =20
        =20
        powerAttributesMIBObjects OBJECT IDENTIFIER=20
            ::=3D { powerAttributesMIB 1 }=20
        =20
        -- Objects=20
        =20
        =20
        eoACPwrAttributesTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoACPwrAttributesEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
                "This table defines power attributes measurements for=20
                supported entPhysicalIndex entities. It is a sparse=20
                extension of the eoPowerTable."=20
            ::=3D { powerAttributesMIBObjects 1 }=20
     =20
     =20
               Expires June 13, 2014          [Page 54]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
        eoACPwrAttributesEntry OBJECT-TYPE=20
            SYNTAX          EoACPwrAttributesEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
                "This is a sparse extension of the eoPowerTable with=20
                entries for power attributes measurements or=20
                configuration.  Each measured value corresponds to an=20
                attribute in IEC 61850-7-4 for non-phase measurements=20
                within the object MMUX."=20
            =20
        INDEX {entPhysicalIndex }=20
            ::=3D { eoACPwrAttributesTable 1 }=20
        =20
        EoACPwrAttributesEntry ::=3D SEQUENCE {=20
            eoACPwrAttributesConfiguration       INTEGER,   =20
            eoACPwrAttributesAvgVoltage          Integer32,=20
            eoACPwrAttributesAvgCurrent          Integer32,=20
            eoACPwrAttributesFrequency           Integer32,=20
            eoACPwrAttributesPowerUnitMultiplier UnitMultiplier,=20
            eoACPwrAttributesPowerAccuracy       Integer32,=20
            eoACPwrAttributesTotalActivePower    Integer32,=20
            eoACPwrAttributesTotalReactivePower  Integer32,=20
            eoACPwrAttributesTotalApparentPower  Integer32,=20
            eoACPwrAttributesTotalPowerFactor    Integer32, =20
            eoACPwrAttributesThdAmpheres         Integer32,=20
            eoACPwrAttributesThdVoltage          Integer32=20
        }=20
        =20
        eoACPwrAttributesConfiguration OBJECT-TYPE=20
            SYNTAX INTEGER { =20
                sngl(1), =20
                del(2), =20
                wye(3)=20
                           }=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                 "Configuration describes the physical configurations=20
                 of the power supply lines:=20
                 =20
                    * alternating current, single phase (SNGL)=20
                    * alternating current, three phase delta (DEL)=20
                    * alternating current, three phase Y (WYE)=20
                 =20
                 Three-phase configurations can be either connected in=20=

                 a triangular delta (DEL) or star Y (WYE) system.  WYE=20=

     =20
     =20
               Expires June 13, 2014          [Page 55]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                 systems have a shared neutral voltage, while DEL=20
                 systems do not.  Each phase is offset 120 degrees to=20
                 each other."=20
            ::=3D { eoACPwrAttributesEntry 1 }=20
        =20
        eoACPwrAttributesAvgVoltage OBJECT-TYPE=20
            SYNTAX          Integer32=20
            UNITS           "0.1 Volt AC"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value for average of the voltage measured=20
                over an integral number of AC cycles   For a 3-phase=20
                system, this is the average voltage (V1+V2+V3)/3.  IEC=20=

                61850-7-4 measured value attribute 'Vol'"=20
            ::=3D { eoACPwrAttributesEntry 2 }=20
        =20
        eoACPwrAttributesAvgCurrent OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positive numbers only? I can't see how =
you could have negative avg amps.

            UNITS           "Ampheres"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value of the current per phase. IEC 61850-
                7-4 attribute 'Amp'"=20
            ::=3D { eoACPwrAttributesEntry 3 }=20
        =20
        eoACPwrAttributesFrequency OBJECT-TYPE=20
            SYNTAX          Integer32 (4500..6500) -- UNITS 0.01 Hertz=20=

            UNITS           "hertz"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value for the basic frequency of the AC=20
                circuit.  IEC 61850-7-4 attribute 'Hz'."=20
            ::=3D { eoACPwrAttributesEntry 4 }=20
        =20
        eoACPwrAttributesPowerUnitMultiplier OBJECT-TYPE=20
            SYNTAX          UnitMultiplier=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "The magnitude of watts for the usage value in=20
                eoACPwrAttributesTotalActivePower,=20
                eoACPwrAttributesTotalReactivePower =20
                and eoACPwrAttributesTotalApparentPower measurements.  =20=

                For 3-phase power systems, this will also include =20

     =20
     =20
               Expires June 13, 2014          [Page 56]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                eoACPwrAttributesPhaseActivePower,=20
                eoACPwrAttributesPhaseReactivePower and=20
                eoACPwrAttributesPhaseApparentPower" =20
            ::=3D { eoACPwrAttributesEntry 5 }=20
        =20
        eoACPwrAttributesPowerAccuracy OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "This object indicates a percentage value, in 100ths of=20=

                a percent, representing the presumed accuracy of=20
                active, reactive, and apparent power usage reporting.=20
                For example: 1010 means the reported usage is accurate=20=

                to +/- 10.1 percent.  This value is zero if the=20
                accuracy is unknown.=20
                =20
                ANSI and IEC define the following accuracy classes for=20=

                power measurement: IEC 62053-22 & 60044-1 class 0.1,=20
                0.2, 0.5, 1 & 3.=20
                ANSI C12.20 class 0.2 & 0.5"=20
            ::=3D { eoACPwrAttributesEntry 6 }=20
        =20
        eoACPwrAttributesTotalActivePower OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           " watts"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value of the actual power delivered to or=20
                consumed by the load.  IEC 61850-7-4 attribute 'TotW'."=20=

            ::=3D { eoACPwrAttributesEntry 7 }=20
        =20
        eoACPwrAttributesTotalReactivePower OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positive numbers only? I can't see how =
you could have negative amps.

            UNITS           "volt-amperes reactive"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A mesured value of the reactive portion of the=20
                apparent power.  IEC 61850-7-4 attribute 'TotVAr'."=20
            ::=3D { eoACPwrAttributesEntry 8 }=20
        =20
        eoACPwrAttributesTotalApparentPower OBJECT-TYPE=20
            SYNTAX          Integer32 =20

TOM: Should this be limited to positive numbers only? I can't see how =
you could have negative amps.

            UNITS           "volt-amperes"=20
            MAX-ACCESS      read-only=20
     =20
     =20
               Expires June 13, 2014          [Page 57]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value of the voltage and current which=20
                determines the apparent power.  The apparent power is=20
                the vector sum of real and reactive power. =20
                 =20
                Note: watts and volt-ampheres are equivalent units and=20=

                may be combined.  IEC 61850-7-4 attribute 'TotVA'."=20
            ::=3D { eoACPwrAttributesEntry 9 }=20
        =20
        eoACPwrAttributesTotalPowerFactor OBJECT-TYPE=20
            SYNTAX          Integer32 (-10000..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value ratio of the real power flowing to=20
                the load versus the apparent power. It is dimensionless=20=

                and expressed here as a percentage value in 100ths of a=20=

                percent. A power factor of 100% indicates there is no=20
                inductance load and thus no reactive power. Power=20
                Factor can be positive or negative, where the sign=20
                should be in lead/lag (IEEE) form.  IEC 61850-7-4=20
                attribute 'TotPF'."=20
            ::=3D { eoACPwrAttributesEntry 10 }=20
        =20
        eoACPwrAttributesThdAmpheres OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A calculated value for the current total harmonic=20
                distortion (THD).  Method of calculation is not=20
                specified.  IEC 61850-7-4 attribute 'ThdAmp'."=20
            ::=3D { eoACPwrAttributesEntry 11 }=20
        =20
        eoACPwrAttributesThdVoltage OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A calculated value for the voltage total harmonic=20
                distortion (THD).  Method of calculation is not=20
                specified.  IEC 61850-7-4 attribute 'ThdVol'."=20
            ::=3D { eoACPwrAttributesEntry 12 }=20
        =20
     =20
     =20
               Expires June 13, 2014          [Page 58]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        eoACPwrAttributesPhaseTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoACPwrAttributesPhaseEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
                "This table describes 3-phase power attributes=20
                measurements.  It is a sparse extension of the=20
                eoACPwrAttributesTable."=20
            ::=3D { powerAttributesMIBObjects 2 }=20
        =20
        =20
        eoACPwrAttributesPhaseEntry OBJECT-TYPE=20
            SYNTAX          EoACPwrAttributesPhaseEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
                "An entry describes common 3-phase power attributes=20
                measurements.=20
                =20
                This optional table describes 3-phase power attributes=20=

                measurements, with three entries for each supported=20
                entPhysicalIndex entity.  Entities having single phase=20=

                power shall not have any entities. =20
                =20
                This table describes attributes common to both WYE and=20=

                DEL.  Entities having single phase power shall not have=20=

                any entries here.  It is a sparse extension of the=20
                eoACPwrAttributesTable.  =20
                =20
                These attributes correspond to IEC 61850-7.4 MMXU phase=20=

                measurements."=20
            INDEX { entPhysicalIndex, eoPhaseIndex }=20
            ::=3D { eoACPwrAttributesPhaseTable 1 }=20
        =20
        EoACPwrAttributesPhaseEntry ::=3D SEQUENCE {=20
                eoPhaseIndex                    Integer32,=20
                eoACPwrAttributesPhaseAvgCurrent      Integer32,=20
                eoACPwrAttributesPhaseActivePower    Integer32,=20
                eoACPwrAttributesPhaseReactivePower   Integer32,=20
                eoACPwrAttributesPhaseApparentPower   Integer32,=20
                eoACPwrAttributesPhasePowerFactor      Integer32,     =20=

                eoACPwrAttributesPhaseImpedance       Integer32  =20
                }=20
        =20
        eoPhaseIndex OBJECT-TYPE=20
            SYNTAX          Integer32 (0..359)=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
     =20
     =20
               Expires June 13, 2014          [Page 59]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            DESCRIPTION=20
               "A phase angle typically corresponding to 0, 120, 240."=20=

             ::=3D { eoACPwrAttributesPhaseEntry 1 }=20
        =20
        eoACPwrAttributesPhaseAvgCurrent OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only? Can't have negative =
current.

            UNITS           "Ampheres"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value of the current per phase. IEC 61850-
                7-4 attribute 'A'"=20
            ::=3D { eoACPwrAttributesPhaseEntry 2 }=20
        =20
        eoACPwrAttributesPhaseActivePower OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           " watts"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value of the actual power delivered to or=20
                consumed by the load. IEC 61850-7-4 attribute 'W'"=20
            ::=3D { eoACPwrAttributesPhaseEntry 3 }=20
        =20
        eoACPwrAttributesPhaseReactivePower OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           "volt-amperes reactive"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value of the reactive portion of the=20
                apparent power.  IEC 61850-7-4 attribute 'VAr'"=20
            ::=3D { eoACPwrAttributesPhaseEntry 4 }=20
        =20
        eoACPwrAttributesPhaseApparentPower OBJECT-TYPE=20
            SYNTAX          Integer32 =20

TOM: Should this be limited to positives only?

            UNITS           "volt-amperes"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value of the voltage and current determines=20=

                the apparent power.  Active plus reactive power equals=20=

                the total apparent power.=20
                 =20
                Note: Watts and volt-ampheres are equivalent units and=20=

                may be combined.  IEC 61850-7-4 attribute 'VA'."=20
            ::=3D { eoACPwrAttributesPhaseEntry 5 }=20
        =20
     =20
     =20
               Expires June 13, 2014          [Page 60]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        eoACPwrAttributesPhasePowerFactor OBJECT-TYPE=20
            SYNTAX          Integer32 (-10000..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
                "A measured value ratio of the real power flowing to=20
                the load versus the apparent power for this phase.  IEC=20=

                61850-7-4 attribute 'PF'. Power Factor can be positive=20=

                or negative where the sign should be in lead/lag (IEEE)=20=

                form."=20
            ::=3D { eoACPwrAttributesPhaseEntry 6 }=20
        =20
        eoACPwrAttributesPhaseImpedance OBJECT-TYPE=20
            SYNTAX          Integer32 =20

TOM: Should this be limited to positives only?

            UNITS           "volt-amperes"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
        "A measured value of the impedance.  IEC 61850-7-4 attribute=20
        'Z'."=20
            ::=3D { eoACPwrAttributesPhaseEntry 7 }=20
        =20
        eoACPwrAttributesDelPhaseTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoACPwrAttributesDelPhaseEntry =20=

            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "This table describes DEL configuration phase-to-phase=20
               power attributes measurements.  This is a sparse=20
               extension of the eoACPwrAttributesPhaseTable."=20
            ::=3D { powerAttributesMIBObjects 3 }=20
        =20
        eoACPwrAttributesDelPhaseEntry OBJECT-TYPE=20
            SYNTAX          EoACPwrAttributesDelPhaseEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "An entry describes  power attributes attributes of a=20
               phase in a DEL 3-phase power system.  Voltage=20
               measurements are provided both relative to each other=20
               and zero.=20
               =20
               Measured values are from IEC 61850-7-2 MMUX and THD from=20=

               MHAI objects.=20
               =20


     =20
     =20
               Expires June 13, 2014          [Page 61]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
               For phase-to-phase measurements, the eoPhaseIndex is=20
               compared against the following phase at +120 degrees. =20
               Thus, the possible values are:=20
               =20
                             eoPhaseIndex        Next Phase Angle=20
                                   0                 120=20
                                 120                 240=20
                                 240                   0   =20
               "=20
            INDEX { entPhysicalIndex, eoPhaseIndex}=20
            ::=3D { eoACPwrAttributesDelPhaseTable 1}=20
        =20
        EoACPwrAttributesDelPhaseEntry ::=3D SEQUENCE {=20
            eoACPwrAttributesDelPhaseToNextPhaseVoltage      Integer32,=20=

            eoACPwrAttributesDelThdPhaseToNextPhaseVoltage   Integer32,=20=

            eoACPwrAttributesDelThdCurrent                  Integer32=20
        }=20
        =20
        eoACPwrAttributesDelPhaseToNextPhaseVoltage OBJECT-TYPE=20
            SYNTAX          Integer32=20

TOM: Should this be limited to positives only?

            UNITS           "0.1 Volt AC"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "A measured value of phase to next phase voltages, where=20=

               the next phase is IEC 61850-7-4 attribute 'PPV'."=20
            ::=3D { eoACPwrAttributesDelPhaseEntry 2 }=20
        =20
        eoACPwrAttributesDelThdPhaseToNextPhaseVoltage OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20

TOM: Should this be limited to positives only?

            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "A calculated value for the voltage total harmonic=20
               disortion for phase to next phase. Method of calculation=20=

               is not specified.  IEC 61850-7-4 attribute 'ThdPPV'."=20
            ::=3D { eoACPwrAttributesDelPhaseEntry 3 }=20
        =20
        eoACPwrAttributesDelThdCurrent OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
          DESCRIPTION =20
               "A calculated value for the voltage total harmonic=20
               disortion (THD) for phase to phase.  Method of=20
               calculation is not specified.  =20
     =20
     =20
               Expires June 13, 2014          [Page 62]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
               IEC 61850-7-4 attribute 'ThdPPV'."=20
            ::=3D { eoACPwrAttributesDelPhaseEntry 4 }=20
        =20
        eoACPwrAttributesWyePhaseTable OBJECT-TYPE=20
            SYNTAX          SEQUENCE OF EoACPwrAttributesWyePhaseEntry =20=

            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "This table describes WYE configuration phase-to-neutral=20=

               power attributes measurements.  This is a sparse=20
               extension of the eoACPwrAttributesPhaseTable."=20
            ::=3D { powerAttributesMIBObjects 4 }=20
        =20
        eoACPwrAttributesWyePhaseEntry OBJECT-TYPE=20
            SYNTAX          EoACPwrAttributesWyePhaseEntry=20
            MAX-ACCESS      not-accessible=20
            STATUS          current=20
            DESCRIPTION=20
               "This table describes measurements of WYE configuration=20=


TOM: would be nice to decode WHY for the reader.

               with phase to neutral power attributes attributes. Three=20=

               entries are required for each supported entPhysicalIndex=20=

               entry.  Voltage measurements are relative to neutral.=20
               =20
               This is a sparse extension of the=20
               eoACPwrAttributesPhaseTable.=20
               =20
               Each entry describes power attributes attributes of one=20=

               phase of a WYE 3-phase power system.=20
               =20
               Measured values are from IEC 61850-7-2 MMUX and THD from=20=

               MHAI objects."=20
            INDEX {  entPhysicalIndex, eoPhaseIndex }=20
            ::=3D { eoACPwrAttributesWyePhaseTable 1}=20
        =20
        EoACPwrAttributesWyePhaseEntry ::=3D SEQUENCE {=20
             eoACPwrAttributesWyePhaseToNeutralVoltage  Integer32,=20
             eoACPwrAttributesWyePhaseCurrent                Integer32,=20=

             eoACPwrAttributesWyeThdPhaseToNeutralVoltage    Integer32=20=

        }=20
        =20
        eoACPwrAttributesWyePhaseToNeutralVoltage OBJECT-TYPE=20
            SYNTAX          Integer32=20
            UNITS           "0.1 Volt AC"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "A measured value of phase to neutral voltage.  IEC=20
               61850-7-4 attribute 'PhV'."=20
     =20
     =20
               Expires June 13, 2014          [Page 63]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            ::=3D { eoACPwrAttributesWyePhaseEntry 1 }=20
        =20
        eoACPwrAttributesWyePhaseCurrent OBJECT-TYPE=20
            SYNTAX          Integer32=20
            UNITS           "0.1 ampheres AC"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "A measured value of phase currents.  IEC 61850-7-4=20
               attribute 'A'."=20
            ::=3D { eoACPwrAttributesWyePhaseEntry 2 }=20
        =20
        eoACPwrAttributesWyeThdPhaseToNeutralVoltage OBJECT-TYPE=20
            SYNTAX          Integer32 (0..10000)=20
            UNITS           "hundredths of percent"=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "A calculated value of the voltage total harmonic=20
               distortion (THD) for phase to neutral. IEC 61850-7-4=20
               attribute 'ThdPhV'."=20
            ::=3D { eoACPwrAttributesWyePhaseEntry 3 }=20
        =20
        -- Conformance=20
        =20
        =20
        powerAttributesMIBCompliances  OBJECT IDENTIFIER=20
            ::=3D { powerAttributesMIB 2 }=20
        =20
        powerAttributesMIBGroups  OBJECT IDENTIFIER=20
            ::=3D { powerAttributesMIB 3 }=20
        =20
        =20
        powerAttributesMIBFullCompliance MODULE-COMPLIANCE=20
            STATUS          current=20
            DESCRIPTION=20
            "When this MIB is implemented with support for read-create,  =
 =20
             then such an implementation can claim full compliance. =20
             Such devices can then be both monitored and configured with =
=20
             this MIB. =20
     =20
             Module Compliance of [RFC6933] with respect to=20
             entity4CRCompliance should be supported which requires=20
             implementation of 3 MIB objects (entPhysicalIndex,=20
             entPhysicalName and entPhysicalUUID)."=20
        =20
        =20
            MODULE          -- this module=20
     =20
     =20
               Expires June 13, 2014          [Page 64]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            MANDATORY-GROUPS {=20
                             powerACPwrAttributesMIBTableGroup=20
                                      }=20
        =20
        =20
            GROUP        powerACPwrAttributesOptionalMIBTableGroup=20
            DESCRIPTION=20
               "A compliant implementation does not have =20
               to implement."=20
               =20
               =20
            GROUP       powerACPwrAttributesPhaseMIBTableGroup=20
            DESCRIPTION=20
                "A compliant implementation does not have to=20
               implement."=20
        =20
            GROUP       powerACPwrAttributesDelPhaseMIBTableGroup     =20=

            DESCRIPTION=20
                "A compliant implementation does not have to=20
               implement."=20
        =20
            GROUP       powerACPwrAttributesWyePhaseMIBTableGroup=20
            DESCRIPTION=20
                "A compliant implementation does not have to=20
               implement."=20
               =20
     =20
            ::=3D { powerAttributesMIBCompliances 1 }=20
        =20
        =20
        =20
        -- Units of Conformance=20
        =20
        powerACPwrAttributesMIBTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                         -- Note that object entPhysicalIndex is NOT =20
                         -- included since it is not-accessible=20
         =20
                                eoACPwrAttributesAvgVoltage,=20
                                eoACPwrAttributesAvgCurrent,=20
                                eoACPwrAttributesFrequency,=20
                                eoACPwrAttributesPowerUnitMultiplier,=20
                                eoACPwrAttributesPowerAccuracy,=20
                                eoACPwrAttributesTotalActivePower,=20
                                eoACPwrAttributesTotalReactivePower,=20
                                eoACPwrAttributesTotalApparentPower,=20
                                eoACPwrAttributesTotalPowerFactor=20
                                                    }    =20
     =20
     =20
               Expires June 13, 2014          [Page 65]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            STATUS          current=20
            DESCRIPTION=20
               "This group contains the collection of all the power=20
               attributes objects related to the Energy Object."=20
            ::=3D { powerAttributesMIBGroups  1 }=20
        =20
         powerACPwrAttributesOptionalMIBTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                                eoACPwrAttributesConfiguration,=20
                                eoACPwrAttributesThdAmpheres,=20
                                eoACPwrAttributesThdVoltage=20
                            }    =20
            STATUS          current=20
            DESCRIPTION=20
               "This group contains the collection of all the power=20
               attributes objects related to the Energy Object."=20
            ::=3D { powerAttributesMIBGroups  2 }=20
        =20
        =20
        powerACPwrAttributesPhaseMIBTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                                -- Note that object entPhysicalIndex is  =
=20
                                -- NOT included since it is =20
                                -- not-accessible=20
                              eoACPwrAttributesPhaseAvgCurrent,=20
                              eoACPwrAttributesPhaseActivePower,=20
                              eoACPwrAttributesPhaseReactivePower,=20
                              eoACPwrAttributesPhaseApparentPower,=20
                              eoACPwrAttributesPhasePowerFactor, =20
                              eoACPwrAttributesPhaseImpedance    =20
                            }=20
            STATUS          current=20
            DESCRIPTION=20
               "This group contains the collection of all 3-phase power=20=

               attributes objects related to the Power State."=20
            ::=3D { powerAttributesMIBGroups  3  }=20
        =20
        powerACPwrAttributesDelPhaseMIBTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                            -- Note that object entPhysicalIndex and =20
                            -- eoPhaseIndex are NOT included=20
                            -- since they are not-accessible=20
                       eoACPwrAttributesDelPhaseToNextPhaseVoltage ,=20
                       eoACPwrAttributesDelThdPhaseToNextPhaseVoltage,=20=

                       eoACPwrAttributesDelThdCurrent=20
                            }=20
            STATUS          current=20
            DESCRIPTION=20
     =20
     =20
               Expires June 13, 2014          [Page 66]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
                "This group contains the collection of all power=20
                characteristic attributes of a phase in a DEL 3-phase=20
                power system."=20
            ::=3D { powerAttributesMIBGroups  4  }=20
        =20
        powerACPwrAttributesWyePhaseMIBTableGroup OBJECT-GROUP=20
            OBJECTS         {=20
                               -- Note that object entPhysicalIndex and =20=

                               -- eoPhaseIndex are NOT included=20
                               -- since they are not-accessible=20
                       eoACPwrAttributesWyePhaseToNeutralVoltage,=20
                       eoACPwrAttributesWyePhaseCurrent,=20
                       eoACPwrAttributesWyeThdPhaseToNeutralVoltage=20
                            }=20
            STATUS          current=20
            DESCRIPTION=20
                "This group contains the collection of all WYE=20
                configuration phase-to-neutral power attributes=20
                measurements."=20
            ::=3D { powerAttributesMIBGroups  5  }=20
     =20
        =20
        END=20
        =20
     =20
     =20
     =20

     =20
     IANA-POWERSTATE-SET-MIB DEFINITIONS ::=3D BEGIN=20
          IMPORTS=20
            MODULE-IDENTITY, mib-2=20
                      FROM SNMPv2-SMI=20
            TEXTUAL-CONVENTION=20
                FROM SNMPv2-TC;=20
        =20
          ianaPowerStateSetMIB MODULE-IDENTITY=20
            LAST-UPDATED "201312130000Z"  -- December 13, 2013=20
            ORGANIZATION "IANA"=20
            CONTACT-INFO "        =20
                          Internet Assigned Numbers Authority=20
                          Postal: ICANN=20
                          4676 Admiralty Way, Suite 330=20
                          Marina del Rey, CA 90292=20
                          Tel: +1-310-823-9358=20
                          EMail: iana&iana.org"=20
     =20
     =20
     =20
     =20
               Expires June 13, 2014          [Page 67]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
            DESCRIPTION=20
             "This MIB module defines a TEXTUAL-CONVENTION that=20
              describes the relationships between Energy Objects.=20
     =20
              Copyright (C) The IETF Trust (2013).=20
     =20
              The initial version of this MIB module was published in=20
              RFC YYY; for full legal notices see the RFC itself.=20
              Supplementary information may be available at=20
              http://www.ietf.org/copyrights/ianamib.html"=20
                          =20
     =20
            REVISION     "201312130000Z"  -- December 13, 2013=20
            DESCRIPTION  "Initial version of this MIB as published in=20
                          RFC YYY."       =20
            ::=3D { energyMIB 5 }=20
        =20
          -- RFC Editor, please replace YYY with the IANA allocation=20
          -- for this MIB module and YYY with the number of the  =20
          -- approved RFC=20
        =20
          -- Textual Conventions =20
     =20
     =20
     IANAPowerStateSet::=3D TEXTUAL-CONVENTION =20
         STATUS     current =20
         DESCRIPTION =20
     =20
               "IANAPowerState is a textual convention that describes  =20=

         Power State Sets and Power State Set Values an Energy Object =20=

         supports. IANA has created a registry of Power State supported=20=

         by an Energy Object and IANA shall administer the list of =20
         Power State Sets and Power States.=20
     =20
          The textual convention assumes that Power States in a power=20
          state set are limited to 255 distinct values. For a Power=20
          State Set S, the named number with the value S * 256 is=20
          allocated to indicate the Power State set. For a Power State X=20=

          in the Power State S, the named number with the value S * 256=20=

          + X + 1 is allocated to represent the Power State."=20
                     =20
         REFERENCE =20
            "http://www.iana.org/assignments/eman =20
     =20
             RFC EDITOR NOTE: please change the previous URL if this is =20=

             not the correct one after IANA assigned it." =20
                   =20
         SYNTAX      INTEGER {=20
     =20
     =20
               Expires June 13, 2014          [Page 68]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
       =20
                           other(0),        -- indicates other set=20
                           unknown(255),    -- unknown =20
      =20
                           ieee1621(256), -- indicates IEEE1621 set=20
                           ieee1621On(257),=20
                           ieee1621Off(258),=20
                           ieee1621Sleep(259),=20
      =20
                           dmtf(512),   -- indicates DMTF set=20
                           dmtfOn(513),=20
                           dmtfSleepLight(514),=20
                           dmtfSleepDeep(515),=20
                           dmtfOffHard(516),=20
                           dmtfOffSoft(517),=20
                           dmtfHibernate(518),=20
                           dmtfPowerOffSoft(519),=20
                           dmtfPowerOffHard(520),=20
                           dmtfMasterBusReset(521),=20
                           dmtfDiagnosticInterrapt(522),=20
                           dmtfOffSoftGraceful(523),=20
                           dmtfOffHardGraceful(524),=20
                           dmtfMasterBusResetGraceful(525),=20
                           dmtfPowerCycleOffSoftGraceful(526),=20
                           dmtfPowerCycleHardGraceful(527),=20
     =20
                           eman(1024),       -- indicates EMAN set=20
                           emanmechoff(1025),=20
                           emansoftoff(1026),     =20
                           emanhibernate(1027),   =20
                           emansleep(1028),=20
                           emanstandby(1029),=20
                           emanready(1030),  =20
                           emanlowMinus(1031),    =20
                           emanlow(1032),=20
                           emanmediumMinus(1033),=20
                           emanmedium(1034), =20
                           emanhighMinus(1035),   =20
                           emanhigh(1036)                        =20
                       }=20
     =20
     END=20
     =20
        =20
     11. Implementation Status =20

        =20

     =20
     =20
               Expires June 13, 2014          [Page 69]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        [Note to RFC Editor: Please remove this section and the=20
        reference to [RFC6982] before publication.]=20
        =20
        This section records the status of known implementations of the=20=

        EMAN-Monitoring MIB at the time of posting of this Internet-
        Draft, and is based on a proposal described in [RFC6982].=20
           =20
        The description of implementations in this section is intended=20=

        to assist the IETF in its decision processes in progressing=20
        drafts to RFCs.  =20
        =20
     11.1. SNMP Research =20

        =20
             Organization:     SNMP Research, Inc.=20
        =20
             Maturity:   Prototype based upon early drafts of the MIBs. =20=

                         We anticipate updating it to more recent =20
                         documents as development schedules allow.=20
        =20
             Coverage:   Code was generated to implement all MIB objects =
=20
                         in ENTITY-MIB (Version 4), =20
                         ENERGY-OBJECT-CONTEXT-MIB,=20
                         ENERGY-OBJECT-MIB,=20
                         POWER-ATTRIBUTES-MIB, =20
                         and BATTERY-MIB.=20
        =20
             Implementation experience: The documents are implementable.=20=

        =20
             Comments:   Technical comments about the =20
                         ENERGY-OBJECT-CONTEXT-MIB,=20
                         ENERGY-OBJECT-MIB, and =20
                         BATTERY-MIB =20
                         were submitted to the EMAN Working Group =20
                         E-mail list. =20
        =20
             Licensing:  Proprietary, royalty licensing=20
        =20
             Contact:    Alan Luchuk, luchuk at snmp.com=20
        =20
             URL:        http://www.snmp.com/=20
        =20
        =20
     11.2. Cisco Systems=20

        =20
             Organization:     Cisco Systems, Inc.=20
        =20
     =20
     =20
               Expires June 13, 2014          [Page 70]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
             Maturity:   Prototype based upon early version drafts of =20=

                         the MIBs. We anticipate updating the MIB =20
                         modules as when the drafts are updated. =20
        =20
             Coverage:   Code was generated to implement all MIB objects=20=

                         in the ENTITY-MIB (Version 4), and =20
                         ENERGY-OBJECT-MIB.=20
                         =20
             Implementation experience:  The MIB modules are implemented=20=

                         on Cisco router platforms to measure and report=20=

                         router energy measurements. The documents are =20=

                         implementable.=20
        =20
             Licensing:  Proprietary =20
        =20
             URL:        http://www.cisco.com =20
     =20
        =20
     12. Security Considerations=20

        Some of the readable objects in these MIB modules (i.e., objects=20=

        with a MAX-ACCESS other than not-accessible) may be considered=20=

        sensitive or vulnerable in some network environments.  It is=20
        thus important to control even GET and/or NOTIFY access to these=20=

        objects and possibly to even encrypt the values of these objects=20=

        when sending them over the network via SNMP.  =20
        =20
        There are a number of management objects defined in these MIB=20
        modules with a MAX-ACCESS clause of read-write and/or read-
        create.  Such objects MAY be considered sensitive or vulnerable=20=

        in some network environments.  The support for SET operations in=20=

        a non-secure environment without proper protection can have a=20
        negative effect on network operations.  The following are the=20
        tables and objects and their sensitivity/vulnerability:=20
        =20
        - Unauthorized changes to the eoPowerOperState (via=20
          theeoPowerAdminState ) MAY disrupt the power settings of the=20=

          differentEnergy Objects, and therefore the state of=20
          functionality of the respective Energy Objects.=20
        - Unauthorized changes to the eoEnergyParametersTable MAY=20
          disrupt energy measurement in the eoEnergyTable table. =20
        =20
        SNMP versions prior to SNMPv3 did not include adequate security.=20=

        Even if the network itself is secure (for example, by using=20
        IPsec), there is still no secure control over who on the secure=20=

        network is allowed to access and GET/SET=20
        (read/change/create/delete) the objects in these MIB modules.=20
        =20
     =20
     =20
               Expires June 13, 2014          [Page 71]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        It is RECOMMENDED that implementers consider the security=20
        features as provided by the SNMPv3 framework (see [RFC3410],=20
        section 8), including full support for the SNMPv3 cryptographic=20=

        mechanisms (for authentication and privacy).=20
        =20
        Further, deployment of SNMP versions prior to SNMPv3 is NOT=20
        RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to=20=

        enable cryptographic security.  It is then a customer/operator=20=

        responsibility to ensure that the SNMP entity giving access to=20=

        an instance of these MIB modules is properly configured to give=20=

        access to the objects only to those principals (users) that have=20=

        legitimate rights to GET or SET (change/create/delete) them.=20
        =20

     13. IANA Considerations=20

        Additions to the ENERGY-OBJECT-MIB MIB and POWER-ATTRIBUTES-MIB=20=

        MIB modules are subject to Expert Review [RFC5226], i.e., review=20=

        by one of a group of experts designated by an IETF Area=20
        Director.  The group of experts MUST check the requested MIB=20
        objects for completeness and accuracy of the description. =20
        Requests for MIB objects that duplicate the functionality of=20
        existing objects SHOULD be declined.  The smallest available=20
        OIDs SHOULD be assigned to the new MIB objects.  The=20
        specification of new MIB objects SHOULD follow the structure=20
        specified in Section 10. and MUST be published using a well-

TOM: The period after 10 is unnecessary.

        established and persistent publication medium.  =20

        =20

     13.1. IANA Registration of new Power State Set=20

        The initial set of Power State Sets are specified in [EMAN-
        FMWK]. IANA maintains a Textual Convention IANAPowerStateSet=20
        with the initial set of Power State Sets and the Power States=20
        within those Power State Sets as proposed in the [EMAN-FMWK].=20
        The current version of IANAPowerStateSet Textual convention can=20=

        be accessed http://www.iana.org/assignments/IANAPowerStateSet.=20=


        New Assignments (and potential deprecation) to Power State Sets=20=

        shall be administered by   IANA and the guidelines and=20
        procedures are specified in [EMAN-FMWK], and will, as a=20
        consequence, the IANAPowerStateSet Textual Convention should be=20=

        updated. =20

        =20

     13.1.1. IANA Registration of the IEEE1621 Power State Set=20
     =20
     =20
               Expires June 13, 2014          [Page 72]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        The Internet Assigned Numbers Authority (IANA) has created a new=20=

        registry for IEEE1621 Power State Set identifiers and filled it=20=

        with the initial list in the Textual Convention=20
        IANAPowerStateSet. =20

        =20

        Guidelines for new assignments (or potentially deprecation) for=20=

        IEEE1621 Power State Set are specified in [EMAN-FMWK].=20

     13.1.2. IANA Registration of the DMTF Power State Set=20

        The Internet Assigned Numbers Authority (IANA) has created a new=20=

        registry for DMTF Power State Set identifiers and filled it in=20=

        the Textual Convention IANAPowerStateSet.=20

        Guidelines for new assignments (or potentially deprecation) for=20=

        DMTF Power State Set are specified in [EMAN-FMWK].=20

     13.1.3. IANA Registration of the EMAN Power State Set=20

        The Internet Assigned Numbers Authority (IANA) has created a new=20=

        registry for EMAN Power State Set identifiers and filled it in=20=

        the Textual Convention IANAPowerStateSet.=20

        Guidelines for new assignments (or potentially deprecation) for=20=

        EMAN Power State Set are specified in [EMAN-FMWK].=20

     14. Contributors=20

        This document results from the merger of two initial proposals.=20=

        The following persons made significant contributions either in=20=

        one of the initial proposals or in this document.=20
        =20
        John Parello=20
        =20
        Rolf Winter=20
        =20
        Dominique Dudkowski=20
     =20

     12. Acknowledgment=20

        The authors would like to thank Shamita Pisal for her prototype=20=

        of this MIB module, and her valuable feedback.  The authors=20
        would like to Michael Brown for improving the text dramatically.=20=

     =20

     =20
     =20
               Expires June 13, 2014          [Page 73]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        The authors would like to thank Juergen Schoenwalder for=20
        proposing the design of the Textual Convention for=20
        IANAPowerStateSet and Ira McDonald for his feedback. Thanks for=20=

        the many comments on the design of the EnergyTable from Minoru=20=

        Teraoka and Hiroto Ogaki.=20
        =20
        Many thanks to Alan Luchuk for the detailed review of the MIB=20
        and his comments.=20
        =20
        And finally, thanks to the EMAN chairs: Nevil Brownlee and Tom=20=

        Nadeau.=20
     =20
     =20
     13. References=20

      13.1. Normative References=20

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate=20
                Requirement Levels, BCP 14, RFC 2119, March 1997.=20
        =20
        [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.=20
                Schoenwaelder, Ed., "Structure of Management=20
                Information Version 2 (SMIv2)", STD 58, RFC 2578, April=20=

                1999.=20
        =20
        [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.=20
                Schoenwaelder, Ed., "Textual Conventions for SMIv2",=20
                STD 58, RFC 2579, April 1999.=20
        =20
        [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,=20
                "Conformance Statements for SMIv2", STD 58, RFC 2580,=20
                April 1999.=20
     =20
        [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",=20
                RFC3621, December 2003.=20
     =20
        [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version=20=

                3)", RFC 4133, August 2005.=20
     =20
        [EMAN-AWARE-MIB] J. Parello, B. Claise and M. Chandramoili,=20
                "draft-ietf-eman-energy-aware-mib-11 ", work in=20
                progress, November 2013.=20
        =20
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management Information=20=

                Base extension module for TIA-TR41.4 media endpoint=20
                discovery information", July 2005.=20
        =20
     =20
     =20
     =20
               Expires June 13, 2014          [Page 74]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
      13.2. Informative References=20

        =20
        [RFC1628] S. Bradner, "UPS Management Information Base", RFC=20
                1628, May 1994 =20
        =20
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,=20
                "Introduction and Applicability Statements for Internet=20=

                Standard Management Framework ", RFC 3410, December=20
                2002.=20
         =20
        [RFC3418]  Presun, R., Case, J., McCloghrie, K., Rose, M, and S.=20=

                Waldbusser, "Management Information Base (MIB) for the=20=

                Simple Network Management Protocol (SNMP)", RFC3418,=20
                December 2002.=20
        =20
        [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity=20=

                Sensor Management Information Base", RFC 3433, December=20=

                2002.=20
        =20
        [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC=20=

                4268, November 2005.=20
        =20
        [RFC5226]  Narten, T. Alverstrand, H., A. and K. McCloghrie,=20
                "Guidelines for Writing an IANA Considerations Section=20=

                in RFCs ", BCP 26, RFC 5226, May 2008.=20
        =20
        [RFC6933] A. Bierman, D. Romascanu, J. Quittek and M.=20
                Chandramouli " Entity MIB (Version 4)", RFC 6933, May=20
                2013. =20
        =20
        [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of=20
                Running Code: The Implementation Status Section", RFC=20
                6982, July 2013.=20
        =20
        [RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M.=20=

                Chandramouli, " Requirements for Energy Management",=20
                RFC 6988, September 2013. =20
        =20
        [EMAN-FMWK] Parello, J. Claise, B., Schoening, B. and Quittek,=20=

                J., "Energy Management Framework", draft-ietf-eman-
                framework-11, October 2013.=20
     =20
        [EMAN-AS] Schoening, B., Chandramouli, M. and Nordman, B.=20
                "Energy Management (EMAN) Applicability Statement",=20
                draft-ietf-eman-applicability-statement-04, October=20
                2013.=20
     =20
     =20
               Expires June 13, 2014          [Page 75]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
        =20
        [ACPI] "Advanced Configuration and Power Interface=20
                Specification",http://www.acpi.info/DOWNLOADS/ACPIspec3
                0b.pdf =20
        =20
        [DMTF] "Power State Management Profile DMTF  DSP1027  Version=20
                2.0"  December 2009    =20
                http://www.dmtf.org/sites/default/files/standards/docum
                ents/DSP1027_2.0.0.pdf=20
        =20
        [IEEE1621]  "Standard for User Interface Elements in Power=20
                Control of Electronic Devices Employed in=20
                Office/Consumer Environments", IEEE 1621, December=20
                2004. =20
        =20
        [IEC.61850-7-4] International Electrotechnical Commission,=20
                "Communication networks and systems for power utility=20
                automation Part 7-4: Basic communication structure=20
                Compatible logical node classes and data object=20
                classes", 2010.=20
        =20
        [IEC.62053-21] International Electrotechnical Commission,=20
                "Electricity metering equipment (a.c.) Particular=20
                requirements Part 22: Static meters for active energy =20=

                (classes 1 and 2)", 2003.=20
        =20
        [IEC.62053-22]International Electrotechnical Commission,=20
                "Electricity metering equipment (a.c.) Particular=20
                requirements Part 22: Static meters for active energy =20=

                (classes 0,2 S and 0,5 S)", 2003.=20
     =20
        =20
     Authors' Addresses=20
        =20
      =20
      Mouli Chandramouli=20
      Cisco Systems, Inc.=20
      Sarjapur Outer Ring Road=20
      Bangalore 560103=20
      IN=20
      =20
      Phone: +91 80 4429 2409 =20
      Email: moulchan@cisco.com=20
      =20
      =20
      Benoit Claise=20
      Cisco Systems, Inc.=20
      De Kleetlaan 6a b1=20
     =20
     =20
               Expires June 13, 2014          [Page 76]=20=

        =20
=0C     Internet-Draft    December 2013=20=

     =20
      Diegem 1813=20
      BE=20
         =20
      Phone: +32 2 704 5622=20
      Email: bclaise@cisco.com=20
      =20
      =20
      Brad Schoening=20
      44 Rivers Edge Drive=20
      Little Silver, NJ 07739=20
      US=20
      Email: brad.schoening@verizon.net=20
      =20
      =20
      Juergen Quittek=20
      NEC Europe Ltd.=20
      NEC Laboratories Europe=20
      Network Research Division=20
      Kurfuersten-Anlage 36=20
      Heidelberg  69115=20
      DE=20
      =20
      Phone: +49 6221 4342-115=20
      Email: quittek@neclab.eu=20
      =20
      =20
      Thomas Dietz=20
      NEC Europe Ltd.=20
      NEC Laboratories Europe=20
      Network Research Division=20
      Kurfuersten-Anlage 36=20
      Heidelberg  69115=20
      DE=20
      =20
      Phone: +49 6221 4342-128=20
      Email: Thomas.Dietz@neclab.eu=20
     =20








     =20
     =20
               Expires June 13, 2014          [Page 77]=20=

        =20



--Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS4ZoFAAoJEPcO+I7eiUJZFdMP/0zYCq/ChYTJwF1nUtVcBevU
vMvs7OpXNFBuF6ANxDztZrfcN2Rg5nx5ou8K7ZG/dV9ePXUUOKtDi68avgm1S7PR
ndFY44JxPjZMPtJBI1EBTYATlaZxWWSSaAN3tmS8RbLM8AtMoHaFkTM4ELVzYPvZ
qQyixoWKI40gWPlIXq3vD4tmtu+MjBoAg9aQlcVfL5MRTQSmOYwARFk+0Lrl1yJ+
YT8QZHdIBkQDkND+Osc2ei4aLD9qyExoj2NNJytrouvpVJeBQiImXLUBqd/NfZTX
5ho3AUxmzJeGZhCJH5vz9itQYZhEnqQhQV7XISpNPRsrxQCtpHUhJDYxIYiOkB6v
I/c4hnPvudEzlfMzaAfAa5efKVXTvMGq/XdHsOPrJKNK496OFy6f2Bqvunw71/yQ
dDudsRCcx38QDp0Yhpq9AHNQWI552PDcM4DLpj42ZynlBcYZMSgFZZRkNgb2doze
OgamLwTGfHlOX9NUL9/SePLa1nMvdtgxi1Mqpr2LNOsrNTyOODIdC+B0kwJkSZZn
06H5aako7ymmgq08C2pgo8ybrrxw5D3iuZFUa0aKTdPhkXUkTNqZ8vjN8f/EzPMl
TpPRd2CIvo50axx/xvOqFXw4JR2eBsaGGCN41Agmo7WD9VvG8BUl8cuxrk+5BS5h
OHBjmAtdDFWFV4LdqNYd
=q5LJ
-----END PGP SIGNATURE-----

--Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D--

From bclaise@cisco.com  Fri Jan 24 02:51:09 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F77D1A022A for ; Fri, 24 Jan 2014 02:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 AQaPGvAcvMjs for ; Fri, 24 Jan 2014 02:51:07 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0C1A0226 for ; Fri, 24 Jan 2014 02:51:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3602; q=dns/txt; s=iport; t=1390560666; x=1391770266; h=message-id:date:from:mime-version:to:cc:subject; bh=qbOSRjseMg08InwhHg2WZv7pc5PPVOjw62kjCkAFmZM=; b=dUyLFM5/GCqqUGEJ9ZcAf306hUgiDnt6e2tZTfe4FB0VfPgTYw7fDjIc CTWcA+LBxonWWvSzQR+2CfzpoB+3r+Y/SBIJRSeX1GxTT2MzzgGw8XYFi Szqy1SR1iwASsM4lHAxJSVFxbBiQsUGWM4Yon6WqMbt0E0olDnuz6g6My k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAGVE4lKQ/khL/2dsb2JhbABagwy9RYEOFnSDJAEfHRYYAwIBAgFLDQEHAQGIAcgBF48AhD8EmCaGR4tXgy47
X-IronPort-AV: E=Sophos;i="4.95,712,1384300800"; d="scan'208,217";a="3453438"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 10:51:05 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0OAp5ke027792; Fri, 24 Jan 2014 10:51:05 GMT
Message-ID: <52E24599.9020200@cisco.com>
Date: Fri, 24 Jan 2014 11:51:05 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "MIB Doctors (E-mail)" 
Content-Type: multipart/alternative; boundary="------------020209090401040902060000"
Cc: draft-ietf-eman-energy-monitoring-mib@tools.ietf.org, draft-ietf-eman-energy-aware-mib.all@tools.ietf.org
Subject: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 10:51:09 -0000

This is a multi-part message in MIME format.
--------------020209090401040902060000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Is there some standard text to explain what  "rwn" (read, write, notify) 
for object trees mean?
For example:

   +- eoTable(2)
            |
            +- eoEntry(1) [entPhysicalIndex]
            |  |
            |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
            |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
            |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
            |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
            |  +-- r-n InetAddressType              eoMgmtAddressType(5)
            |  +-- r-n InetAddress                  eoMgmtAddress(6)
            |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
            |  +-- rwn SnmpAdminString              eoDomainName(8)
            |  +-- rwn SnmpAdminString              eoRoleDescription(9)
            |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
            |  +-- rwn Integer32                    eoImportance(11)
            |  +-- r-n INTEGER                      eoPowerCategory(12)
            |  +-- rwn SnmpAdminString              eoAlternateKey(13)
            |  +-- r-n INTEGER                   eoPowerInterfaceType(14)

Regards, Benoit


--------------020209090401040902060000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    
      Dear all,

        

        Is there some standard text to explain what  "rwn" (read, write, notify) for
        object trees mean?

      For example:

    
  +- eoTable(2) 
           | 
           +- eoEntry(1) [entPhysicalIndex] 
           |  |  
           |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1) 
           |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2) 
           |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3) 
           |  +-- rwn MacAddress                   eoMgmtMacAddress(4) 
           |  +-- r-n InetAddressType              eoMgmtAddressType(5) 
           |  +-- r-n InetAddress                  eoMgmtAddress(6) 
           |  +-- r-n SnmpAdminString              eoMgmtDNSName(7) 
           |  +-- rwn SnmpAdminString              eoDomainName(8) 
           |  +-- rwn SnmpAdminString              eoRoleDescription(9) 
           |  +-- rwn EnergyObjectKeywordList      eoKeywords(10) 
           |  +-- rwn Integer32                    eoImportance(11) 
           |  +-- r-n INTEGER                      eoPowerCategory(12) 
           |  +-- rwn SnmpAdminString              eoAlternateKey(13) 
           |  +-- r-n INTEGER                   eoPowerInterfaceType(14) 

Regards, Benoit


  


--------------020209090401040902060000--

From Quittek@neclab.eu  Fri Jan 24 03:14:39 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EE81A022A for ; Fri, 24 Jan 2014 03:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level: 
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 8jO7YI5mb9ra for ; Fri, 24 Jan 2014 03:14:37 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0592A1A0295 for ; Fri, 24 Jan 2014 03:14:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 84604106A10; Fri, 24 Jan 2014 12:14:33 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9x8sFSyYNqn; Fri, 24 Jan 2014 12:14:33 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 682E3106A2D; Fri, 24 Jan 2014 12:14:13 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 24 Jan 2014 12:14:14 +0100
From: Juergen Quittek 
To: Benoit Claise , "MIB Doctors (E-mail)" 
Thread-Topic: rwn for MIB specifications?
Thread-Index: AQHPGPJGHGTvu9C2j0qtqAeDU3Wd7ZqTtSrg
Date: Fri, 24 Jan 2014 11:14:12 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
References: <52E24599.9020200@cisco.com>
In-Reply-To: <52E24599.9020200@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.2.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-eman-energy-monitoring-mib@tools.ietf.org" , "draft-ietf-eman-energy-aware-mib.all@tools.ietf.org" 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 11:14:40 -0000

Hi Benoit,=20
I have not seen any text documenting this format in a standards document, y=
et.
The obvious meaning of the three symbols is a compressed representation of =
the object's MAX-ACCESS clause which may have the following values:=20
    "not-accessible"->"---"
    "accessible-for-notify"->"--n"
    "read-only"->"r-n"
    "read-write"->"rwn"
    "read-create"->"rwn" (why not "rcn"?)
Juergen

> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Freitag, 24. Januar 2014 11:51
> To: MIB Doctors (E-mail)
> Cc: draft-ietf-eman-energy-aware-mib.all@tools.ietf.org; draft-ietf-eman-
> energy-monitoring-mib@tools.ietf.org
> Subject: rwn for MIB specifications?
>=20
> Dear all,
>=20
> Is there some standard text to explain what  "rwn" (read, write, notify) =
for
> object trees mean?
> For example:
>=20
>   +- eoTable(2)
>            |
>            +- eoEntry(1) [entPhysicalIndex]
>            |  |
>            |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
>            |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
>            |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
>            |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
>            |  +-- r-n InetAddressType              eoMgmtAddressType(5)
>            |  +-- r-n InetAddress                  eoMgmtAddress(6)
>            |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
>            |  +-- rwn SnmpAdminString              eoDomainName(8)
>            |  +-- rwn SnmpAdminString              eoRoleDescription(9)
>            |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
>            |  +-- rwn Integer32                    eoImportance(11)
>            |  +-- r-n INTEGER                      eoPowerCategory(12)
>            |  +-- rwn SnmpAdminString              eoAlternateKey(13)
>            |  +-- r-n INTEGER                   eoPowerInterfaceType(14)
>=20
> Regards, Benoit

From bclaise@cisco.com  Fri Jan 24 03:14:43 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF621A0265; Fri, 24 Jan 2014 03:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kNuV3ffwncyc; Fri, 24 Jan 2014 03:14:40 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id AF4D41A029B; Fri, 24 Jan 2014 03:14:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17578; q=dns/txt; s=iport; t=1390562075; x=1391771675; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=SmxysjEkgHRULLjm7zMmQ2tXJTpnhsfIYQCAWJuokV8=; b=Mwtsrj2OOL+sohrLFL1cGCg7AijeuVP0wzu53JbIZmKTOBmsGsax/sDB qU3X97R/7zpQq/M1DLGgxj4Wd/8Z3S8krIfq9jmzcWC5bW4052fN/wgfp iRTno5scnbjUsg+e2/lMNKFW9BHAi5EYTOzhK4sA7fBh2Wqcic5sYH/tI A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnIJAD5K4lKQ/khN/2dsb2JhbABQBAaDDDi1bocfgQwWdIIlAQEBAwF4EQsOExYPCQMCAQIBRQYBDAgBAYd5CA3HexcGAY4dBQkLSoQ4BJgmgTKFFYtXgy47gS0
X-IronPort-AV: E=Sophos;i="4.95,712,1384300800"; d="scan'208,217";a="3454678"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 11:14:33 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0OBEXAg027480; Fri, 24 Jan 2014 11:14:33 GMT
Message-ID: <52E24B19.7000606@cisco.com>
Date: Fri, 24 Jan 2014 12:14:33 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Thomas Nadeau , "MIB Doctors (E-mail)" , eman mailing list 
References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com>
In-Reply-To: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com>
Content-Type: multipart/alternative; boundary="------------030503090106020909090300"
Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 11:14:43 -0000

This is a multi-part message in MIME format.
--------------030503090106020909090300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tom,
>      
>            
>          Every Energy Object MUST have a printable name assigned to it.
>
> TOM: Can you be more specific with "printable"?  Do you mean ASCII etc...?
This is direct cut and paste from the framework.
We had bound to SnmpAdminString, which says UTF-8
Type 	SnmpAdminString
Status 	current
MIB 	SNMP-FRAMEWORK-MIB 
; 
   - View Supporting Images 
 

Description 	"An octet string containing administrative
information, preferably in human-readable form.

To facilitate internationalization, this
information is represented using the ISO/IEC
IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format
described in [RFC2279].

Since additional code points are added by
amendments to the 10646 standard from time
to time, implementations must be prepared to
encounter any code point from 0x00000000 to
0x7fffffff. Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or are outside this range are
prohibited.

The use of control codes should be avoided.

When it is necessary to represent a newline,
the control code sequence CR LF should be used.


The use of leading or trailing white space should
be avoided.

For code points not directly supported by user
interface hardware or software, an alternative
means of entry and display, such as hexadecimal,
may be provided.

For information encoded in 7-bit US-ASCII,
the UTF-8 encoding is identical to the
US-ASCII encoding.

UTF-8 may require multiple bytes to represent a
single character / code point; thus the length
of this object in octets may be different from
the number of characters encoded. Similarly,
size constraints refer to the number of encoded
octets, not the number of characters represented
by an encoding.

Note that when this TC is used for an object that
is used or envisioned to be used as an index, then
a SIZE restriction MUST be specified so that the
number of sub-identifiers for any object instance
does not exceed the limit of 128, as defined by
[RFC3416].


Do you want us to mention UTF-8?
>           
>       5.3 Links to Other Identifiers
>
>          While the entPhysicalIndex is the primary index for all MIB
>          objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy
>          Management Systems (EnMS) must be able to make the link with the
>
> TOM: Do you really mean (all caps) MUST here?
RFC 6988:

    4.4.  Using Entity Identifiers of Existing MIB Modules

        The standard must provide means for reusing entity identifiers from
        existing standards, including at least the following:

        o  the entPhysicalIndex in the Entity MIB module [RFC6933]

        o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
           the LLDP-MED MIB module [ANSI-TIA-1057]

        o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
           Ethernet MIB [RFC3621]

        Generic means for reusing other entity identifiers must be provided.

So a MUST is right.
>
>          modules for the Energy Objects. However, in situation where any
>          of these two MIB modules are implemented, the EnMS must be able
>          to correlate the instances in the different MIB modules.
>           
>          The eoAlternateKey alternate key object specifies a manufacturer
>          defined string that can be used to identify the Energy Object.
>          Since an EnMS may need to correlate objects across management
>        
>        
>              Expires  June 13, 2014           [Page 10]
>           
>      Internet-Draft   < Energy Object Context MIB >     December 2013
>        
>          systems, this alternate key is provided to facilitate such a
>          link.  This optional value is intended as a foreign key or
>          alternate identifier for a manufacturer or EnMS to use to
>          correlate the unique Energy Object Id in other systems or
>          namespaces. If an alternate key is not available or is not
>          applicable then the value is the zero-length string.
>
> TOM: Do you want to use MUST here to indicate that it MUST be the zero-length string?
Ok.
>           
>                                      
>          -- Textual Conventions
>
> TOM: The naming of all of these objects is unusual. The "PethPse" prefix in particular. Typically MIB variables and tables are somehow related to the module/table they are contained in.  It would be burdensome to rename every thing in the module at this point, so I would be happy if you simply defined what these prefixes meant for the uninitiated reader.
The logic was:

PethPsePortIndexOrZero is taken from the existing pethPsePortIndex TC
PethPsePortGroupIndexOrZero is taken from the exiting pethPsePortGroupIndex TC


>        
>          eoMgmtDNSName OBJECT-TYPE
>              SYNTAX          SnmpAdminString
>              MAX-ACCESS      read-only
>              STATUS          current
>              DESCRIPTION
>                 "This object specifies the DNS name of the eoMgmtAddress.
>                 This object can be used as an alternate key to help link
>                 the Energy Object with other keyed information that may
>                 be stored within the EnMS(s)."
>              ::= { eoEntry 7  }
>
> TOM: Is there anything you want to say about any (suggested) format for this string?
We will search for an existing DNS MIB and copy it
>        
>          eoDomainName OBJECT-TYPE
>              SYNTAX          SnmpAdminString
>              MAX-ACCESS      read-write
>              STATUS          current
>              DESCRIPTION
>                 "This object specifies the name of an Energy Management
>                 Domain for the Energy Object.  This object specifies a
>                 zero-length string value if no Energy Management Domain
>                 name is configured. The value of eoDomainName must remain
>                 constant at least from one re-initialization of the
>                 entity local management system to the next re-
>                 initialization."
>        
>        
>              Expires  June 13, 2014           [Page 18]
>           
>      Internet-Draft   < Energy Object Context MIB >     December 2013
>        
>              ::= { eoEntry 8   }
>
> TOM: Should this be an empty string by default so that it is set into a known state?
Make sense

Regards, Benoit

--------------030503090106020909090300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Tom,

    

    

      
    
          
        Every Energy Object MUST have a printable name assigned to it. 

TOM: Can you be more specific with "printable"?  Do you mean ASCII etc...? 

    

    This is direct cut and paste from the framework.

    We had bound to SnmpAdminString, which says UTF-8

    

      
        

          Type
          SnmpAdminString
        

        

          Status
          current
        

        

          MIB
             SNMP-FRAMEWORK-MIB ;   -  
               View
                Supporting Images   
        

        

          Description
          "An octet string
              containing administrative

              information, preferably in human-readable form.

              

              To facilitate internationalization, this

              information is represented using the ISO/IEC

              IS 10646-1 character set, encoded as an octet

              string using the UTF-8 transformation format

              described in [RFC2279].

              

              Since additional code points are added by

              amendments to the 10646 standard from time

              to time, implementations must be prepared to

              encounter any code point from 0x00000000 to

              0x7fffffff. Byte sequences that do not

              correspond to the valid UTF-8 encoding of a

              code point or are outside this range are

              prohibited.

              

              The use of control codes should be avoided.

              

              When it is necessary to represent a newline,

              the control code sequence CR LF should be used.

              

              

              The use of leading or trailing white space should

              be avoided.

              

              For code points not directly supported by user

              interface hardware or software, an alternative

              means of entry and display, such as hexadecimal,

              may be provided.

              

              For information encoded in 7-bit US-ASCII,

              the UTF-8 encoding is identical to the

              US-ASCII encoding.

              

              UTF-8 may require multiple bytes to represent a

              single character / code point; thus the length

              of this object in octets may be different from

              the number of characters encoded. Similarly,

              size constraints refer to the number of encoded

              octets, not the number of characters represented

              by an encoding.

              

              Note that when this TC is used for an object that

              is used or envisioned to be used as an index, then

              a SIZE restriction MUST be specified so that the

              number of sub-identifiers for any object instance

              does not exceed the limit of 128, as defined by

              [RFC3416].		
        

      
    

    

    Do you want us to mention UTF-8?

    

      
         
     5.3 Links to Other Identifiers    

        While the entPhysicalIndex is the primary index for all MIB 
        objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy 
        Management Systems (EnMS) must be able to make the link with the 

TOM: Do you really mean (all caps) MUST here?

    

    RFC 6988:

    

      
4.4.  Using Entity Identifiers of Existing MIB Modules

   The standard must provide means for reusing entity identifiers from
   existing standards, including at least the following:

   o  the entPhysicalIndex in the Entity MIB module [RFC6933]

   o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
      the LLDP-MED MIB module [ANSI-TIA-1057]

   o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
      Ethernet MIB [RFC3621]

   Generic means for reusing other entity identifiers must be provided.

    

    So a MUST is right.

    

      

        modules for the Energy Objects. However, in situation where any 
        of these two MIB modules are implemented, the EnMS must be able 
        to correlate the instances in the different MIB modules. 
         
        The eoAlternateKey alternate key object specifies a manufacturer 
        defined string that can be used to identify the Energy Object.  
        Since an EnMS may need to correlate objects across management 
      
      
     <Parello, Claise>       Expires  June 13, 2014           [Page 10] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        systems, this alternate key is provided to facilitate such a 
        link.  This optional value is intended as a foreign key or 
        alternate identifier for a manufacturer or EnMS to use to 
        correlate the unique Energy Object Id in other systems or 
        namespaces. If an alternate key is not available or is not 
        applicable then the value is the zero-length string. 

TOM: Do you want to use MUST here to indicate that it MUST be the zero-length string? 

    

    Ok.

    

      
         
                                    
        -- Textual Conventions 

TOM: The naming of all of these objects is unusual. The "PethPse" prefix in particular. Typically MIB variables and tables are somehow related to the module/table they are contained in.  It would be burdensome to rename every thing in the module at this point, so I would be happy if you simply defined what these prefixes meant for the uninitiated reader.  

    

    The logic was:   

    
PethPsePortIndexOrZero is taken from the existing pethPsePortIndex TC
PethPsePortGroupIndexOrZero is taken from the exiting pethPsePortGroupIndex TC

    

    

      
      
        eoMgmtDNSName OBJECT-TYPE 
            SYNTAX          SnmpAdminString 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
               "This object specifies the DNS name of the eoMgmtAddress. 
               This object can be used as an alternate key to help link 
               the Energy Object with other keyed information that may 
               be stored within the EnMS(s)." 
            ::= { eoEntry 7  } 

TOM: Is there anything you want to say about any (suggested) format for this string?

    

    We will search for an existing DNS MIB and copy it

    

      
      
        eoDomainName OBJECT-TYPE 
            SYNTAX          SnmpAdminString 
            MAX-ACCESS      read-write 
            STATUS          current 
            DESCRIPTION 
               "This object specifies the name of an Energy Management 
               Domain for the Energy Object.  This object specifies a 
               zero-length string value if no Energy Management Domain 
               name is configured. The value of eoDomainName must remain 
               constant at least from one re-initialization of the 
               entity local management system to the next re-
               initialization."  
      
      
     <Parello, Claise>       Expires  June 13, 2014           [Page 18] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
            ::= { eoEntry 8   } 

TOM: Should this be an empty string by default so that it is set into a known state?

    

    Make sense

    

    Regards, Benoit

  


--------------030503090106020909090300--

From bclaise@cisco.com  Fri Jan 24 03:27:44 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0DB1A02BA for ; Fri, 24 Jan 2014 03:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 5YJ7XSXJkPzr for ; Fri, 24 Jan 2014 03:27:43 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id C4E001A02B8 for ; Fri, 24 Jan 2014 03:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2150; q=dns/txt; s=iport; t=1390562862; x=1391772462; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=47+aIxZVpWZDnX6dzJJd16O/JoU0HmYCfpLynwZDyPA=; b=V+t3SI296pz9X4Sfb28hH8FidoqiE+B5mCM5g7Pc2Ih8jTNQoW7+/LqN VJ9eCRX2YmrRJ/U/SH5lx+OXrlfe3LkhKrhJgNUUWlTDh+c0PeiGvPxLg /9hrYz7qpwDAAJprfSvmwV6uSzFjt8kJtujnxupRTk9h5lkQglhf3ms3u o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFAL9N4lKQ/khR/2dsb2JhbABagwy9RYEMFnSCJQEBAQQnCwEFQAEMBAsRBAEBChYIBwkDAgECATQJCAYBDAEFAgEBiAHICxePAAcGhDIBA5gmhkeLV4MuOw
X-IronPort-AV: E=Sophos;i="4.95,712,1384300800";  d="scan'208";a="3455276"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 11:27:40 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0OBRe1Z011814; Fri, 24 Jan 2014 11:27:40 GMT
Message-ID: <52E24E2C.3070807@cisco.com>
Date: Fri, 24 Jan 2014 12:27:40 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Juergen Quittek , "MIB Doctors (E-mail)" 
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "draft-ietf-eman-energy-monitoring-mib@tools.ietf.org" , "draft-ietf-eman-energy-aware-mib.all@tools.ietf.org" 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 11:27:44 -0000

Hi Jürgen,
> Hi Benoit,
> I have not seen any text documenting this format in a standards document, yet.
> The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values:
>      "not-accessible"->"---"
>      "accessible-for-notify"->"--n"
>      "read-only"->"r-n"
>      "read-write"->"rwn"
>      "read-create"->"rwn" (why not "rcn"?)
Maybe that's all that we need to explain.

Regards, Benoit
> Juergen
>
>> -----Original Message-----
>> From: Benoit Claise [mailto:bclaise@cisco.com]
>> Sent: Freitag, 24. Januar 2014 11:51
>> To: MIB Doctors (E-mail)
>> Cc: draft-ietf-eman-energy-aware-mib.all@tools.ietf.org; draft-ietf-eman-
>> energy-monitoring-mib@tools.ietf.org
>> Subject: rwn for MIB specifications?
>>
>> Dear all,
>>
>> Is there some standard text to explain what  "rwn" (read, write, notify) for
>> object trees mean?
>> For example:
>>
>>    +- eoTable(2)
>>             |
>>             +- eoEntry(1) [entPhysicalIndex]
>>             |  |
>>             |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
>>             |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
>>             |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
>>             |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
>>             |  +-- r-n InetAddressType              eoMgmtAddressType(5)
>>             |  +-- r-n InetAddress                  eoMgmtAddress(6)
>>             |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
>>             |  +-- rwn SnmpAdminString              eoDomainName(8)
>>             |  +-- rwn SnmpAdminString              eoRoleDescription(9)
>>             |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
>>             |  +-- rwn Integer32                    eoImportance(11)
>>             |  +-- r-n INTEGER                      eoPowerCategory(12)
>>             |  +-- rwn SnmpAdminString              eoAlternateKey(13)
>>             |  +-- r-n INTEGER                   eoPowerInterfaceType(14)
>>
>> Regards, Benoit
> .
>


From tnadeau@lucidvision.com  Fri Jan 24 07:24:55 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD71A0294; Fri, 24 Jan 2014 07:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level: 
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 s9Zj9h0UW_G3; Fri, 24 Jan 2014 07:24:52 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 324991A0025; Fri, 24 Jan 2014 07:24:52 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DA3D826C74E2; Fri, 24 Jan 2014 10:24:50 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <52E24B19.7000606@cisco.com>
Date: Fri, 24 Jan 2014 10:24:50 -0500
Message-Id: <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com>
References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.1827)
Cc: "MIB Doctors \(E-mail\)" , eman mailing list 
Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 15:24:56 -0000

--Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF"


--Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Jan 24, 2014:6:14 AM, at 6:14 AM, Benoit Claise  =
wrote:

> Hi Tom,
>>    =20
>>          =20
>>         Every Energy Object MUST have a printable name assigned to =
it.=20
>>=20
>> TOM: Can you be more specific with "printable"?  Do you mean ASCII =
etc...?=20
> This is direct cut and paste from the framework.
> We had bound to SnmpAdminString, which says UTF-8

	That is the kicker - make sure its a UTF-8 encoding specified in =
the description. Right now it reads like a free-form string is ok unless =
you go to the trouble of looking up the reference below.=20


>=20
> Type	SnmpAdminString
> Status	current
> MIB	 SNMP-FRAMEWORK-MIB ;   -   View Supporting Images
> Description	"An octet string containing administrative
> information, preferably in human-readable form.
>=20
> To facilitate internationalization, this
> information is represented using the ISO/IEC
> IS 10646-1 character set, encoded as an octet
> string using the UTF-8 transformation format
> described in [RFC2279].
>=20
> Since additional code points are added by
> amendments to the 10646 standard from time
> to time, implementations must be prepared to
> encounter any code point from 0x00000000 to
> 0x7fffffff. Byte sequences that do not
> correspond to the valid UTF-8 encoding of a
> code point or are outside this range are
> prohibited.
>=20
> The use of control codes should be avoided.
>=20
> When it is necessary to represent a newline,
> the control code sequence CR LF should be used.
>=20
>=20
> The use of leading or trailing white space should
> be avoided.
>=20
> For code points not directly supported by user
> interface hardware or software, an alternative
> means of entry and display, such as hexadecimal,
> may be provided.
>=20
> For information encoded in 7-bit US-ASCII,
> the UTF-8 encoding is identical to the
> US-ASCII encoding.
>=20
> UTF-8 may require multiple bytes to represent a
> single character / code point; thus the length
> of this object in octets may be different from
> the number of characters encoded. Similarly,
> size constraints refer to the number of encoded
> octets, not the number of characters represented
> by an encoding.
>=20
> Note that when this TC is used for an object that
> is used or envisioned to be used as an index, then
> a SIZE restriction MUST be specified so that the
> number of sub-identifiers for any object instance
> does not exceed the limit of 128, as defined by
> [RFC3416].
> Do you want us to mention UTF-8?
>>         =20
>>      5.3 Links to Other Identifiers   =20
>>=20
>>         While the entPhysicalIndex is the primary index for all MIB=20=

>>         objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy=20=

>>         Management Systems (EnMS) must be able to make the link with =
the=20
>>=20
>> TOM: Do you really mean (all caps) MUST here?
> RFC 6988:
> 4.4.  Using Entity Identifiers of Existing MIB Modules
>=20
>    The standard must provide means for reusing entity identifiers from
>    existing standards, including at least the following:
>=20
>    o  the entPhysicalIndex in the Entity MIB module [RFC6933]
>=20
>    o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
>       the LLDP-MED MIB module [ANSI-TIA-1057]
>=20
>    o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
>       Ethernet MIB [RFC3621]
>=20
>    Generic means for reusing other entity identifiers must be =
provided.
> So a MUST is right.
>>=20
>>         modules for the Energy Objects. However, in situation where =
any=20
>>         of these two MIB modules are implemented, the EnMS must be =
able=20
>>         to correlate the instances in the different MIB modules.=20
>>         =20
>>         The eoAlternateKey alternate key object specifies a =
manufacturer=20
>>         defined string that can be used to identify the Energy =
Object. =20
>>         Since an EnMS may need to correlate objects across management=20=

>>      =20
>>      =20
>>             Expires  June 13, 2014           [Page =
10]=20
>>         =20
>> =0C     Internet-Draft   < Energy Object Context MIB >     December =
2013=20
>>      =20
>>         systems, this alternate key is provided to facilitate such a=20=

>>         link.  This optional value is intended as a foreign key or=20
>>         alternate identifier for a manufacturer or EnMS to use to=20
>>         correlate the unique Energy Object Id in other systems or=20
>>         namespaces. If an alternate key is not available or is not=20
>>         applicable then the value is the zero-length string.=20
>>=20
>> TOM: Do you want to use MUST here to indicate that it MUST be the =
zero-length string?=20
> Ok.
>>         =20
>>                                    =20
>>         -- Textual Conventions=20
>>=20
>> TOM: The naming of all of these objects is unusual. The "PethPse" =
prefix in particular. Typically MIB variables and tables are somehow =
related to the module/table they are contained in.  It would be =
burdensome to rename every thing in the module at this point, so I would =
be happy if you simply defined what these prefixes meant for the =
uninitiated reader. =20
> The logic was:  =20
> PethPsePortIndexOrZero is taken from the existing pethPsePortIndex TC
> PethPsePortGroupIndexOrZero is taken from the exiting =
pethPsePortGroupIndex TC

	OK.=20


>=20
>>      =20
>>         eoMgmtDNSName OBJECT-TYPE=20
>>             SYNTAX          SnmpAdminString=20
>>             MAX-ACCESS      read-only=20
>>             STATUS          current=20
>>             DESCRIPTION=20
>>                "This object specifies the DNS name of the =
eoMgmtAddress.=20
>>                This object can be used as an alternate key to help =
link=20
>>                the Energy Object with other keyed information that =
may=20
>>                be stored within the EnMS(s)."=20
>>             ::=3D { eoEntry 7  }=20
>>=20
>> TOM: Is there anything you want to say about any (suggested) format =
for this string?
> We will search for an existing DNS MIB and copy it
>>      =20
>>         eoDomainName OBJECT-TYPE=20
>>             SYNTAX          SnmpAdminString=20
>>             MAX-ACCESS      read-write=20
>>             STATUS          current=20
>>             DESCRIPTION=20
>>                "This object specifies the name of an Energy =
Management=20
>>                Domain for the Energy Object.  This object specifies a=20=

>>                zero-length string value if no Energy Management =
Domain=20
>>                name is configured. The value of eoDomainName must =
remain=20
>>                constant at least from one re-initialization of the=20
>>                entity local management system to the next re-
>>                initialization." =20
>>      =20
>>      =20
>>             Expires  June 13, 2014           [Page =
18]=20
>>         =20
>> =0C     Internet-Draft   < Energy Object Context MIB >     December =
2013=20
>>      =20
>>             ::=3D { eoEntry 8   }=20
>>=20
>> TOM: Should this be an empty string by default so that it is set into =
a known state?
> Make sense
>=20
> Regards, Benoit


--Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


On Jan 24, 2014:6:14 AM, at 6:14 AM, =
Benoit Claise <bclaise@cisco.com> =
wrote:


 =20
    
 =20
  

    
Hi Tom,

    

    

      
   =20
         =20
        Every Energy Object MUST have a printable name assigned to it.=20=


TOM: Can you be more specific with "printable"?  Do you mean ASCII =
etc...? 

    

    This is direct cut and paste from the framework.

    We had bound to SnmpAdminString, which says =
UTF-8

	That is =
the kicker - make sure its a UTF-8 encoding specified in the =
description. Right now it reads like a free-form string is ok unless you =
go to the trouble of looking up the reference =
below. 



    

      
        

          Type
          SnmpAdminString
        

        

          Status
          current
        

        

          MIB
             =
SNMP-FRAMEWORK-MIB ;   -  
               View
                Supporting Images   
        

        

          Description
          "An octet =
string
              containing administrative

              information, preferably in human-readable form.

              

              To facilitate internationalization, this

              information is represented using the ISO/IEC

              IS 10646-1 character set, encoded as an octet

              string using the UTF-8 transformation format

              described in [RFC2279].

              

              Since additional code points are added by

              amendments to the 10646 standard from time

              to time, implementations must be prepared to

              encounter any code point from 0x00000000 to

              0x7fffffff. Byte sequences that do not

              correspond to the valid UTF-8 encoding of a

              code point or are outside this range are

              prohibited.

              

              The use of control codes should be avoided.

              

              When it is necessary to represent a newline,

              the control code sequence CR LF should be used.

              

              

              The use of leading or trailing white space should

              be avoided.

              

              For code points not directly supported by user

              interface hardware or software, an alternative

              means of entry and display, such as hexadecimal,

              may be provided.

              

              For information encoded in 7-bit US-ASCII,

              the UTF-8 encoding is identical to the

              US-ASCII encoding.

              

              UTF-8 may require multiple bytes to represent a

              single character / code point; thus the length

              of this object in octets may be different from

              the number of characters encoded. Similarly,

              size constraints refer to the number of encoded

              octets, not the number of characters represented

              by an encoding.

              

              Note that when this TC is used for an object that

              is used or envisioned to be used as an index, then

              a SIZE restriction MUST be specified so that the

              number of sub-identifiers for any object instance

              does not exceed the limit of 128, as defined by

              [RFC3416].		
        

      
    

    

    Do you want us to mention UTF-8?

    

      
        =20
     5.3 Links to Other Identifiers   =20

        While the entPhysicalIndex is the primary index for all MIB=20
        objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy=20
        Management Systems (EnMS) must be able to make the link with the=20=


TOM: Do you really mean (all caps) MUST here?

    

    RFC 6988:

    

      
4.4.  Using Entity Identifiers of =
Existing MIB Modules

   The standard must provide means for reusing entity identifiers from
   existing standards, including at least the following:

   o  the entPhysicalIndex in the Entity MIB module [RFC6933]

   o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
      the LLDP-MED MIB module [ANSI-TIA-1057]

   o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
      Ethernet MIB [RFC3621]

   Generic means for reusing other entity identifiers must be =
provided.

    

    So a MUST is right.

    

      
        modules for the Energy Objects. However, in situation where any=20=

        of these two MIB modules are implemented, the EnMS must be able=20=

        to correlate the instances in the different MIB modules.=20
        =20
        The eoAlternateKey alternate key object specifies a manufacturer=20=

        defined string that can be used to identify the Energy Object. =20=

        Since an EnMS may need to correlate objects across management=20
     =20
     =20
     <Parello, Claise>       Expires  June 13, 2014           =
[Page 10]=20
        =20
=0C     Internet-Draft   < Energy Object Context MIB >     =
December 2013=20
     =20
        systems, this alternate key is provided to facilitate such a=20
        link.  This optional value is intended as a foreign key or=20
        alternate identifier for a manufacturer or EnMS to use to=20
        correlate the unique Energy Object Id in other systems or=20
        namespaces. If an alternate key is not available or is not=20
        applicable then the value is the zero-length string.=20

TOM: Do you want to use MUST here to indicate that it MUST be the =
zero-length string? 

    

    Ok.

    

      
        =20
                                   =20
        -- Textual Conventions=20

TOM: The naming of all of these objects is unusual. The "PethPse" prefix =
in particular. Typically MIB variables and tables are somehow related to =
the module/table they are contained in.  It would be burdensome to =
rename every thing in the module at this point, so I would be happy if =
you simply defined what these prefixes meant for the uninitiated reader. =
 

    

    The logic was:   

    
PethPsePortIndexOrZero is taken from the existing =
pethPsePortIndex TC
PethPsePortGroupIndexOrZero is taken from the exiting =
pethPsePortGroupIndex =
TC

	=
OK. 



    

    

      
     =20
        eoMgmtDNSName OBJECT-TYPE=20
            SYNTAX          SnmpAdminString=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object specifies the DNS name of the eoMgmtAddress.=20=

               This object can be used as an alternate key to help link=20=

               the Energy Object with other keyed information that may=20=

               be stored within the EnMS(s)."=20
            ::=3D { eoEntry 7  }=20

TOM: Is there anything you want to say about any (suggested) format for =
this string?

    

    We will search for an existing DNS MIB and copy it

    

      
     =20
        eoDomainName OBJECT-TYPE=20
            SYNTAX          SnmpAdminString=20
            MAX-ACCESS      read-write=20
            STATUS          current=20
            DESCRIPTION=20
               "This object specifies the name of an Energy Management=20=

               Domain for the Energy Object.  This object specifies a=20
               zero-length string value if no Energy Management Domain=20=

               name is configured. The value of eoDomainName must remain=20=

               constant at least from one re-initialization of the=20
               entity local management system to the next re-
               initialization." =20
     =20
     =20
     <Parello, Claise>       Expires  June 13, 2014           =
[Page 18]=20
        =20
=0C     Internet-Draft   < Energy Object Context MIB >     =
December 2013=20
     =20
            ::=3D { eoEntry 8   }=20

TOM: Should this be an empty string by default so that it is set into a =
known state?

    

    Make sense

    

    Regards, Benoit

  




=

--Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF--

--Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS4oXDAAoJEPcO+I7eiUJZHDwQAIsyUBQ9dXWy7oW7smrjImdB
bD/nwG/vqDx7q9lc4jmf9v8w30AKQjhmmqJ6Qi72ycRuWDvWW8HxwEC0nMf99OWF
ABNLPeUUjt7TtAwKx0jpXUa26kQkhnkRYhvzrOXnn2xdNO1J6XqOUmugRBzym7cP
7LE9ZCvWejbSmln+5iHfiqCFrMonWa4+Cl4zJ8X2u30czcpFohgJntQBMMvl5CIi
wR8VXPRQmfM0wxHdbcuvJL31WkBLe9dX9ih9rzplenrUi32WHlX2zyoEi8xhXqzV
WUCTD/cbySnH3XpuSjVd4eMPp4/MERKB6mJzvA7uVmQ5sEacNJAVvoOuSUWBt0Xu
5BxVrDzgMcNv3sucSAiRh/weAgB6MZypTcyXoPPXbXrAGKtm4affmtfGxrofd88W
aTLS7u1qUdGCbyVhLTXJQxZM7dpY4VCLM9MvWl55U2XxPe9Kq2iewlDVzlFTPXoZ
mAZISCWgRwXBnvoBDYWpBggkjX/2xjo6qIQFLj/+PH0LeVRkn5Nzonu6nW5/iXNd
/L89fEc3GwdrZVB334sHq6o3lsuy6bzwqaoRh0r5Pe1rtEgVOQovC4vBo0R+Xwf+
m/KsfwJyie1pnwaCRY9VPrTTSeet1VG95s5NMYA4Nv93b///2w9Mji5ETasCJHUD
VcFucSnqJwPwwtjWGO+K
=NR8V
-----END PGP SIGNATURE-----

--Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E--

From tnadeau@lucidvision.com  Fri Jan 24 07:25:32 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22BB1A0020 for ; Fri, 24 Jan 2014 07:25:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 kv_o_Zc6GB-X for ; Fri, 24 Jan 2014 07:25:27 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 57AD61A0025 for ; Fri, 24 Jan 2014 07:25:26 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 26EF826C74F7; Fri, 24 Jan 2014 10:25:25 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_E2F71CF5-D0D7-4DFD-931E-C7ACB8A51C3C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
Date: Fri, 24 Jan 2014 10:25:25 -0500
Message-Id: <1672FFD9-E917-4E97-9851-B13C84619060@lucidvision.com>
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
To: Juergen Quittek 
X-Mailer: Apple Mail (2.1827)
Cc: "MIB Doctors \(E-mail\)" , "draft-ietf-eman-energy-monitoring-mib@tools.ietf.org" , "draft-ietf-eman-energy-aware-mib.all@tools.ietf.org" 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 15:25:33 -0000

--Apple-Mail=_E2F71CF5-D0D7-4DFD-931E-C7ACB8A51C3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	I think that it is useful to put that into the draft to avoid =
any confusion.

	--Tom

On Jan 24, 2014:6:14 AM, at 6:14 AM, Juergen Quittek  =
wrote:

> Hi Benoit,=20
> I have not seen any text documenting this format in a standards =
document, yet.
> The obvious meaning of the three symbols is a compressed =
representation of the object's MAX-ACCESS clause which may have the =
following values:=20
>    "not-accessible"->"---"
>    "accessible-for-notify"->"--n"
>    "read-only"->"r-n"
>    "read-write"->"rwn"
>    "read-create"->"rwn" (why not "rcn"?)
> Juergen
>=20
>> -----Original Message-----
>> From: Benoit Claise [mailto:bclaise@cisco.com]
>> Sent: Freitag, 24. Januar 2014 11:51
>> To: MIB Doctors (E-mail)
>> Cc: draft-ietf-eman-energy-aware-mib.all@tools.ietf.org; =
draft-ietf-eman-
>> energy-monitoring-mib@tools.ietf.org
>> Subject: rwn for MIB specifications?
>>=20
>> Dear all,
>>=20
>> Is there some standard text to explain what  "rwn" (read, write, =
notify) for
>> object trees mean?
>> For example:
>>=20
>>  +- eoTable(2)
>>           |
>>           +- eoEntry(1) [entPhysicalIndex]
>>           |  |
>>           |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
>>           |  +-- r-n PethPsePortGroupIndexOrZero  =
eoEthPortGrpIndex(2)
>>           |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
>>           |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
>>           |  +-- r-n InetAddressType              =
eoMgmtAddressType(5)
>>           |  +-- r-n InetAddress                  eoMgmtAddress(6)
>>           |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
>>           |  +-- rwn SnmpAdminString              eoDomainName(8)
>>           |  +-- rwn SnmpAdminString              =
eoRoleDescription(9)
>>           |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
>>           |  +-- rwn Integer32                    eoImportance(11)
>>           |  +-- r-n INTEGER                      eoPowerCategory(12)
>>           |  +-- rwn SnmpAdminString              eoAlternateKey(13)
>>           |  +-- r-n INTEGER                   =
eoPowerInterfaceType(14)
>>=20
>> Regards, Benoit
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
>=20


--Apple-Mail=_E2F71CF5-D0D7-4DFD-931E-C7ACB8A51C3C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS4oXlAAoJEPcO+I7eiUJZRCUP/isEUouQdEwfNd00xplOhL9W
PzHkhy4w0Vk/95W0IQcbnz6cERtSUkTbVjx+uVmIcMZCwdoEpcyDLli9xfLsupPu
/p+VVewtQR1QBaMbW1xWax1CJugRy2jduShwWRt1fsRQQ54L43JGQbjSeH25NiY/
q77HcefpTRGye5iPpiLafbzyq8mNxCL2NhQHaWb/AadAzb9G8Uib6Yilrqtrx2Hx
KY8Wthla95uGlja/Bhq8Fe0EYhkJxlj8ofvIW/0I82P7uO+avO2QPAgyS6XDgyNI
95+TW7U6nixuE7dO5rALH9Eg55nVbD2/XduKeQTNRpTal0rXl2+vCQGojFkEXwwL
Jqs9/t7oAAfOJCe7bE2+Ykl6TBtuNjCaPyfMx5IFLP/CNBrtEz3B7JDXA8BmZJBX
ErdPVhjWxu6etFKUTSAA3VgE/Wx8o+eb/6FgXDvqiG+IlON5n93J8EbhPFugT7ar
w0ob5ktL1+oPeI4peEA23FQO2eFARHczZeXRM0WXBRP5S6CH2XXC2P17/TxNK0BI
3RLze2lwFfGz9WhQhDftPrykOwdapul3hNAr7lBPYnU0pf3qZSBYbuyE2qXmhoY5
hBmH2AE172IYpi+0WOZat3FtmV5Uw+j1yqfW5e0AxIsSoOm1+/RwBNRXSLYDp2ks
aJxsVD5503bH4IZAUtxr
=YYIB
-----END PGP SIGNATURE-----

--Apple-Mail=_E2F71CF5-D0D7-4DFD-931E-C7ACB8A51C3C--

From Quittek@neclab.eu  Fri Jan 24 08:06:58 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EFC1A04D1 for ; Fri, 24 Jan 2014 08:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level: 
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 rP4gCjsguPaC for ; Fri, 24 Jan 2014 08:06:56 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1FD1A04CD for ; Fri, 24 Jan 2014 08:06:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 98787106A3D; Fri, 24 Jan 2014 17:06:54 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAzuIudmS3V9; Fri, 24 Jan 2014 17:06:54 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 7972D106A3E; Fri, 24 Jan 2014 17:06:29 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 24 Jan 2014 17:06:29 +0100
From: Juergen Quittek 
To: Thomas Nadeau 
Thread-Topic: [MIB-DOCTORS] rwn for MIB specifications?
Thread-Index: AQHPGPJGHGTvu9C2j0qtqAeDU3Wd7ZqTtSrggAA5L4CAABn4wA==
Date: Fri, 24 Jan 2014 16:06:29 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E86890E476@DAPHNIS.office.hd>
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <1672FFD9-E917-4E97-9851-B13C84619060@lucidvision.com>
In-Reply-To: <1672FFD9-E917-4E97-9851-B13C84619060@lucidvision.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.2.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "MIB Doctors \(E-mail\)" , "draft-ietf-eman-energy-monitoring-mib@tools.ietf.org" , "draft-ietf-eman-energy-aware-mib.all@tools.ietf.org" 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 16:06:58 -0000

There are several MIB modules out in RFCs using the tree format of smidump.=
 None of them had a clear documentation of the format and I have not yet se=
en any full documentation of that format anywhere.=20

I think it is the right way to describe it and be clear about what is meant=
. But if we do so, we should document the entire tree format including thin=
gs such as the index in brackets ("[entPhysicalIndex]").

An alternative would be to label the figure as "smidump-style" tree present=
ation of a MIB module or a table within a MIB module.

    Juergen
=20

> -----Original Message-----
> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: Freitag, 24. Januar 2014 16:25
> To: Juergen Quittek
> Cc: Benoit Claise; MIB Doctors (E-mail); draft-ietf-eman-energy-monitorin=
g-
> mib@tools.ietf.org; draft-ietf-eman-energy-aware-mib.all@tools.ietf.org
> Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
>=20
>=20
> 	I think that it is useful to put that into the draft to avoid any confus=
ion.
>=20
> 	--Tom
>=20
> On Jan 24, 2014:6:14 AM, at 6:14 AM, Juergen Quittek 
> wrote:
>=20
> > Hi Benoit,
> > I have not seen any text documenting this format in a standards documen=
t,
> yet.
> > The obvious meaning of the three symbols is a compressed representation=
 of
> the object's MAX-ACCESS clause which may have the following values:
> >    "not-accessible"->"---"
> >    "accessible-for-notify"->"--n"
> >    "read-only"->"r-n"
> >    "read-write"->"rwn"
> >    "read-create"->"rwn" (why not "rcn"?) Juergen
> >
> >> -----Original Message-----
> >> From: Benoit Claise [mailto:bclaise@cisco.com]
> >> Sent: Freitag, 24. Januar 2014 11:51
> >> To: MIB Doctors (E-mail)
> >> Cc: draft-ietf-eman-energy-aware-mib.all@tools.ietf.org;
> >> draft-ietf-eman- energy-monitoring-mib@tools.ietf.org
> >> Subject: rwn for MIB specifications?
> >>
> >> Dear all,
> >>
> >> Is there some standard text to explain what  "rwn" (read, write,
> >> notify) for object trees mean?
> >> For example:
> >>
> >>  +- eoTable(2)
> >>           |
> >>           +- eoEntry(1) [entPhysicalIndex]
> >>           |  |
> >>           |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
> >>           |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
> >>           |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
> >>           |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
> >>           |  +-- r-n InetAddressType              eoMgmtAddressType(5)
> >>           |  +-- r-n InetAddress                  eoMgmtAddress(6)
> >>           |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
> >>           |  +-- rwn SnmpAdminString              eoDomainName(8)
> >>           |  +-- rwn SnmpAdminString              eoRoleDescription(9)
> >>           |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
> >>           |  +-- rwn Integer32                    eoImportance(11)
> >>           |  +-- r-n INTEGER                      eoPowerCategory(12)
> >>           |  +-- rwn SnmpAdminString              eoAlternateKey(13)
> >>           |  +-- r-n INTEGER                   eoPowerInterfaceType(14=
)
> >>
> >> Regards, Benoit
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > MIB-DOCTORS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mib-doctors
> >


From tnadeau@lucidvision.com  Fri Jan 24 08:10:38 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37921A03EF for ; Fri, 24 Jan 2014 08:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 H1VlUlhc6Y43 for ; Fri, 24 Jan 2014 08:10:36 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id EAB6B1A001E for ; Fri, 24 Jan 2014 08:10:35 -0800 (PST)
Received: from [10.108.202.236] (mobile-198-228-193-137.mycingular.net [198.228.193.137]) by lucidvision.com (Postfix) with ESMTP id 2FB6226C776F; Fri, 24 Jan 2014 11:10:33 -0500 (EST)
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <1672FFD9-E917-4E97-9851-B13C84619060@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890E476@DAPHNIS.office.hd>
Mime-Version: 1.0 (1.0)
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E86890E476@DAPHNIS.office.hd>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (11B554a)
From: "Thomas D. Nadeau" 
Date: Fri, 24 Jan 2014 11:10:30 -0500
To: Juergen Quittek 
Cc: "MIB Doctors \(E-mail\)" , "draft-ietf-eman-energy-monitoring-mib@tools.ietf.org" , "draft-ietf-eman-energy-aware-mib.all@tools.ietf.org" 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 16:10:38 -0000

but again you would have to explain what "smidump format" is or provide a re=
ference to somewhere where one could look it up.

Tom=20


> On Jan 24, 2014, at 11:06 AM, Juergen Quittek  wrote:
>=20
> There are several MIB modules out in RFCs using the tree format of smidump=
. None of them had a clear documentation of the format and I have not yet se=
en any full documentation of that format anywhere.=20
>=20
> I think it is the right way to describe it and be clear about what is mean=
t. But if we do so, we should document the entire tree format including thin=
gs such as the index in brackets ("[entPhysicalIndex]").
>=20
> An alternative would be to label the figure as "smidump-style" tree presen=
tation of a MIB module or a table within a MIB module.
>=20
>    Juergen
>=20
>=20
>> -----Original Message-----
>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
>> Sent: Freitag, 24. Januar 2014 16:25
>> To: Juergen Quittek
>> Cc: Benoit Claise; MIB Doctors (E-mail); draft-ietf-eman-energy-monitorin=
g-
>> mib@tools.ietf.org; draft-ietf-eman-energy-aware-mib.all@tools.ietf.org
>> Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
>>=20
>>=20
>>    I think that it is useful to put that into the draft to avoid any conf=
usion.
>>=20
>>    --Tom
>>=20
>> On Jan 24, 2014:6:14 AM, at 6:14 AM, Juergen Quittek 
>> wrote:
>>=20
>>> Hi Benoit,
>>> I have not seen any text documenting this format in a standards document=
,
>> yet.
>>> The obvious meaning of the three symbols is a compressed representation o=
f
>> the object's MAX-ACCESS clause which may have the following values:
>>>   "not-accessible"->"---"
>>>   "accessible-for-notify"->"--n"
>>>   "read-only"->"r-n"
>>>   "read-write"->"rwn"
>>>   "read-create"->"rwn" (why not "rcn"?) Juergen
>>>=20
>>>> -----Original Message-----
>>>> From: Benoit Claise [mailto:bclaise@cisco.com]
>>>> Sent: Freitag, 24. Januar 2014 11:51
>>>> To: MIB Doctors (E-mail)
>>>> Cc: draft-ietf-eman-energy-aware-mib.all@tools.ietf.org;
>>>> draft-ietf-eman- energy-monitoring-mib@tools.ietf.org
>>>> Subject: rwn for MIB specifications?
>>>>=20
>>>> Dear all,
>>>>=20
>>>> Is there some standard text to explain what  "rwn" (read, write,
>>>> notify) for object trees mean?
>>>> For example:
>>>>=20
>>>> +- eoTable(2)
>>>>          |
>>>>          +- eoEntry(1) [entPhysicalIndex]
>>>>          |  |
>>>>          |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
>>>>          |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
>>>>          |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
>>>>          |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
>>>>          |  +-- r-n InetAddressType              eoMgmtAddressType(5)
>>>>          |  +-- r-n InetAddress                  eoMgmtAddress(6)
>>>>          |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
>>>>          |  +-- rwn SnmpAdminString              eoDomainName(8)
>>>>          |  +-- rwn SnmpAdminString              eoRoleDescription(9)
>>>>          |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
>>>>          |  +-- rwn Integer32                    eoImportance(11)
>>>>          |  +-- r-n INTEGER                      eoPowerCategory(12)
>>>>          |  +-- rwn SnmpAdminString              eoAlternateKey(13)
>>>>          |  +-- r-n INTEGER                   eoPowerInterfaceType(14)
>>>>=20
>>>> Regards, Benoit
>>> _______________________________________________
>>> MIB-DOCTORS mailing list
>>> MIB-DOCTORS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>=20
>=20

From j.schoenwaelder@jacobs-university.de  Fri Jan 24 08:31:29 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742801A0026; Fri, 24 Jan 2014 08:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 fsmluQtPZnn9; Fri, 24 Jan 2014 08:31:27 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7F11A0023; Fri, 24 Jan 2014 08:31:27 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81D9820074; Fri, 24 Jan 2014 17:31:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fidXlu4KWafH; Fri, 24 Jan 2014 17:31:25 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42BF32005B; Fri, 24 Jan 2014 17:31:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C3EFA2ACD1C2; Fri, 24 Jan 2014 17:31:21 +0100 (CET)
Date: Fri, 24 Jan 2014 17:31:21 +0100
From: Juergen Schoenwaelder 
To: Thomas Nadeau 
Message-ID: <20140124163121.GD58781@elstar.local>
Mail-Followup-To: Thomas Nadeau , Benoit Claise , "MIB Doctors (E-mail)" , eman mailing list 
References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com> <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "MIB Doctors \(E-mail\)" , eman mailing list 
Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 16:31:29 -0000

On Fri, Jan 24, 2014 at 10:24:50AM -0500, Thomas Nadeau wrote:
> 
> > This is direct cut and paste from the framework.
> > We had bound to SnmpAdminString, which says UTF-8
> 
> 	That is the kicker - make sure its a UTF-8 encoding specified in the description. Right now it reads like a free-form string is ok unless you go to the trouble of looking up the reference below. 
> 

To the defense of the authors, SnmpAdminString is pretty widely used
in SNMP land and I do not recall we generally tend to repeat saying it
is a UTF-8 encoded string when it is used.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From j.schoenwaelder@jacobs-university.de  Fri Jan 24 09:17:37 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B921A04E5 for ; Fri, 24 Jan 2014 09:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 Wtb2ITZAbW4Q for ; Fri, 24 Jan 2014 09:17:32 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C62A11A04D5 for ; Fri, 24 Jan 2014 09:17:31 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FB1120069; Fri, 24 Jan 2014 18:17:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nUsacuXm0H-m; Fri, 24 Jan 2014 18:17:30 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00A3420064; Fri, 24 Jan 2014 18:17:30 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A07252ACD3ED; Fri, 24 Jan 2014 18:17:27 +0100 (CET)
Date: Fri, 24 Jan 2014 18:17:27 +0100
From: Juergen Schoenwaelder 
To: Juergen Quittek 
Message-ID: <20140124171727.GE58781@elstar.local>
Mail-Followup-To: Juergen Quittek , Benoit Claise , "MIB Doctors (E-mail)" 
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "MIB Doctors \(E-mail\)" 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 17:17:37 -0000

On Fri, Jan 24, 2014 at 11:14:12AM +0000, Juergen Quittek wrote:

> The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values: 
>     "not-accessible"->"---"
>     "accessible-for-notify"->"--n"
>     "read-only"->"r-n"
>     "read-write"->"rwn"
>     "read-create"->"rwn" (why not "rcn"?)

The libsmi internally has the 'create' bit on the conceptual row and
not on all conceptual columns like the SMIv2 syntax has it. And as a
consequence, the read-create objects get marked "rwn". And since 'row'
and 'table' nodes do not have access bits in the tree format, the
'create' bit somehow is not shown. From an SMIv2 viewpoint, this
surely looks surprising and "read-create"->"rcn" would likely be a
better solution.

... tak tak tak ...

Turns out it is a two line change to make libsmi generate "rcn"
instead of "rwn". I can be convinced to commit this change if people
think this is a good idea.

There really is no definition of the tree format (but there probably
should be). I also changed it a while ago the format so that it lines
up with the YANG tree format we use (which again was inspired by
smidump's tree format). Smidump's output right now looks like this:

---- snmpCommunityMIB(1.3.6.1.6.3.18)
  +---- snmpCommunityMIBObjects(1)
     +---- snmpCommunityTable(1)
        +---- snmpCommunityEntry(1) [*snmpCommunityIndex]
           +---- snmpCommunityIndex(1)           SnmpAdminString
           +-rcn snmpCommunityName(2)            OctetString
           +-rcn snmpCommunitySecurityName(3)    SnmpAdminString
           +-rcn snmpCommunityContextEngineID(4) SnmpEngineID
           +-rcn snmpCommunityContextName(5)     SnmpAdminString
           +-rcn snmpCommunityTransportTag(6)    SnmpTagValue
           +-rcn snmpCommunityStorageType(7)     StorageType
           +-rcn snmpCommunityStatus(8)          RowStatus

Note that the object descriptor is now always at the same place. One
could consider also consider dropping the OID numbers - for an
overview, these numbers are not really important and they clutter
things up quite a bit. Compare to this:

---- snmpCommunityMIB
  +---- snmpCommunityMIBObjects
     +---- snmpCommunityTable
        +---- snmpCommunityEntry [*snmpCommunityIndex]
           +---- snmpCommunityIndex           SnmpAdminString
           +-rcn snmpCommunityName            OctetString
           +-rcn snmpCommunitySecurityName    SnmpAdminString
           +-rcn snmpCommunityContextEngineID SnmpEngineID
           +-rcn snmpCommunityContextName     SnmpAdminString
           +-rcn snmpCommunityTransportTag    SnmpTagValue
           +-rcn snmpCommunityStorageType     StorageType
           +-rcn snmpCommunityStatus          RowStatus

Should we have such a discussion here?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From tnadeau@lucidvision.com  Fri Jan 24 09:20:57 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0895E1A004B; Fri, 24 Jan 2014 09:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 XEshlE6EYhqi; Fri, 24 Jan 2014 09:20:55 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 23CE11A0047; Fri, 24 Jan 2014 09:20:55 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C4D2626C79F3; Fri, 24 Jan 2014 12:20:53 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <20140124163121.GD58781@elstar.local>
Date: Fri, 24 Jan 2014 12:20:53 -0500
Message-Id: 
References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com> <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com> <20140124163121.GD58781@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1827)
Cc: "MIB Doctors \(E-mail\)" , eman mailing list 
Subject: Re: [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 17:20:57 -0000

--Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 24, 2014:11:31 AM, at 11:31 AM, Juergen Schoenwaelder =
 wrote:

> On Fri, Jan 24, 2014 at 10:24:50AM -0500, Thomas Nadeau wrote:
>>=20
>>> This is direct cut and paste from the framework.
>>> We had bound to SnmpAdminString, which says UTF-8
>>=20
>> 	That is the kicker - make sure its a UTF-8 encoding specified in =
the description. Right now it reads like a free-form string is ok unless =
you go to the trouble of looking up the reference below.=20
>>=20
>=20
> To the defense of the authors, SnmpAdminString is pretty widely used
> in SNMP land and I do not recall we generally tend to repeat saying it
> is a UTF-8 encoded string when it is used.

	Good point. I am %50/%50 on whether its needed to augment the =
text.

	--Tom

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>=20


--Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS4qD1AAoJEPcO+I7eiUJZ7SgP/iLz5ipRGFg3Q6eqRrs7pbGc
cfDy3gN6fzJUBasBbQPDIV0LkM+lvsRMLi5sExpus9UZlTEyjhSdSlnC3czF7Cwd
B99+y4f4Of99r3ZDK8IWtHqitL9jlOKYl24/aJw0Ipx9m6QyQZ3/XVt7hP30NXy4
PTXq8TxOENyfNUkUj57mjVNbgn7k1xkYUsa729Xhk4A2biStjdyXJ0Mu5cqkenJ3
aEbIJJojWAxFerUOeXc9fmLpkTwtTC3ZtBwye+K7aN2LwCrxS85xgC5LMsb0rZIS
riQTR7SI2iw3J2+wmBExmVty9FI0L5qBp4Mn0nYn+IyJGb92EL2Hr0K6+BcSaZzw
AwRMag1q8beLiZlRYMM+WTdm0rMK59grWyLKfTU04724RXAsfXBOdwknPIEoBwRZ
OYmJEYikX4CXfwtq9KDGISoc0TQjV2yzvebNqxwZEVu5PRvBNmRa+v88sHSjEirh
VmAKF+ymgNiT9cbNanGqERLBICLYybRyKAiMbebfuwLwiZwhQMxf5b82YhZ99n5f
2uzTUOb4jfBpVo50AOwWbmLmQPlP5XowIdmVHyg9udKvHAwsyccNz0dlk+Veucx4
OOvjDMusz1D5Jb1V2HBuHyBCpjyayWKuUmv+HpnXTFnjSKMeBiwGUWuEcrg6a4Va
+SbwSU1QR1Km5dI53sto
=rvCK
-----END PGP SIGNATURE-----

--Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51--

From tnadeau@lucidvision.com  Fri Jan 24 09:23:01 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714161A004B for ; Fri, 24 Jan 2014 09:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 1eIaJQK7tr9h for ; Fri, 24 Jan 2014 09:22:59 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3181A0047 for ; Fri, 24 Jan 2014 09:22:59 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0938426C7A16; Fri, 24 Jan 2014 12:22:58 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BF0B3E60-C775-4202-B2E4-E50EE968BA5D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <20140124171727.GE58781@elstar.local>
Date: Fri, 24 Jan 2014 12:22:58 -0500
Message-Id: <4D8B5869-C339-4CAA-8925-B0BE3D51B8F8@lucidvision.com>
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <20140124171727.GE58781@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1827)
Cc: "MIB Doctors \(E-mail\)" , Juergen Quittek 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 17:23:01 -0000

--Apple-Mail=_BF0B3E60-C775-4202-B2E4-E50EE968BA5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 24, 2014:12:17 PM, at 12:17 PM, Juergen Schoenwaelder =
 wrote:

> On Fri, Jan 24, 2014 at 11:14:12AM +0000, Juergen Quittek wrote:
>=20
>> The obvious meaning of the three symbols is a compressed =
representation of the object's MAX-ACCESS clause which may have the =
following values:=20
>>    "not-accessible"->"---"
>>    "accessible-for-notify"->"--n"
>>    "read-only"->"r-n"
>>    "read-write"->"rwn"
>>    "read-create"->"rwn" (why not "rcn"?)
>=20
> The libsmi internally has the 'create' bit on the conceptual row and
> not on all conceptual columns like the SMIv2 syntax has it. And as a
> consequence, the read-create objects get marked "rwn". And since 'row'
> and 'table' nodes do not have access bits in the tree format, the
> 'create' bit somehow is not shown. =46rom an SMIv2 viewpoint, this
> surely looks surprising and "read-create"->"rcn" would likely be a
> better solution.
>=20
> ... tak tak tak ...
>=20
> Turns out it is a two line change to make libsmi generate "rcn"
> instead of "rwn". I can be convinced to commit this change if people
> think this is a good idea.
>=20
> There really is no definition of the tree format (but there probably
> should be). I also changed it a while ago the format so that it lines
> up with the YANG tree format we use (which again was inspired by
> smidump's tree format). Smidump's output right now looks like this:
>=20
> ---- snmpCommunityMIB(1.3.6.1.6.3.18)
>  +---- snmpCommunityMIBObjects(1)
>     +---- snmpCommunityTable(1)
>        +---- snmpCommunityEntry(1) [*snmpCommunityIndex]
>           +---- snmpCommunityIndex(1)           SnmpAdminString
>           +-rcn snmpCommunityName(2)            OctetString
>           +-rcn snmpCommunitySecurityName(3)    SnmpAdminString
>           +-rcn snmpCommunityContextEngineID(4) SnmpEngineID
>           +-rcn snmpCommunityContextName(5)     SnmpAdminString
>           +-rcn snmpCommunityTransportTag(6)    SnmpTagValue
>           +-rcn snmpCommunityStorageType(7)     StorageType
>           +-rcn snmpCommunityStatus(8)          RowStatus
>=20
> Note that the object descriptor is now always at the same place. One
> could consider also consider dropping the OID numbers - for an
> overview, these numbers are not really important and they clutter
> things up quite a bit. Compare to this:
>=20
> ---- snmpCommunityMIB
>  +---- snmpCommunityMIBObjects
>     +---- snmpCommunityTable
>        +---- snmpCommunityEntry [*snmpCommunityIndex]
>           +---- snmpCommunityIndex           SnmpAdminString
>           +-rcn snmpCommunityName            OctetString
>           +-rcn snmpCommunitySecurityName    SnmpAdminString
>           +-rcn snmpCommunityContextEngineID SnmpEngineID
>           +-rcn snmpCommunityContextName     SnmpAdminString
>           +-rcn snmpCommunityTransportTag    SnmpTagValue
>           +-rcn snmpCommunityStorageType     StorageType
>           +-rcn snmpCommunityStatus          RowStatus
>=20
> Should we have such a discussion here?

	That is cool. I think its a good idea to recommend that such =
trees be included in the documents. =20

	--Tom

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
>=20


--Apple-Mail=_BF0B3E60-C775-4202-B2E4-E50EE968BA5D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS4qFyAAoJEPcO+I7eiUJZGhcP/jbWpLo2lpGMIGPW9pQMIjIE
Bc69/z0M89UBjbHRO9z/ehTsgqxkRwQHrze1zFwJmg2LGhkwooSpV7U354djTSP0
kPssY9ooT3JB1VQj4nAQM2ueFl0mr5EELM63NDsA7GcrWoXv8HmQJ4j5MnH5WTmg
sWbMTDdaff960jaC+uB8mzvTYnfcDahqH/iGI3RB8XeY4NtN5bNVEub4/rZdabyy
+8ISwb82YiJR6qVWDhZvUAoCtTlHbxS6QpGHtpGG4D6Dvz9gn7Yv4iMHpvi8iCq5
ulu688UMkD5d2DtolIrvQ+ZyJWpVE3jXxOmHyLb+AtxZ6UqT7A6MyPBbA6212kNM
g9D7fT4EKW6oaBjDT38K10PRFwSBQU6HRE2m+CugazFPV/hlZpELfbT+imbn4x0t
g5HRMfd2dMSFB21p5m8MraHEgOyFMhWrWsQQ0EJ5lpAj317veTGS1Zh1IKAgeK50
rGu2dw1wgdn3DwM9IusBsoO3yI7RxFE3RwuJacR6ffXoGBCBwoexZQmmVID0dCeK
68jvzFSl43tNCHFqm7SS6AMVjy1lZB0PT7XfspbxqQ2um03ZDuHkSkahJ+83unZA
Usz1B3OeBLXkshBn80BXwXezQJJr3MDPCRK9txFsy8nTwv+4s/5BB4K7UVTC1RUK
r71L8JHVL7/XymugYQLU
=HC0q
-----END PGP SIGNATURE-----

--Apple-Mail=_BF0B3E60-C775-4202-B2E4-E50EE968BA5D--

From waldbusser@nextbeacon.com  Fri Jan 24 09:49:15 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8351A0036 for ; Fri, 24 Jan 2014 09:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] 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 wUAKmbbolOWp for ; Fri, 24 Jan 2014 09:49:13 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB61A000B for ; Fri, 24 Jan 2014 09:49:13 -0800 (PST)
Received: from [127.0.0.1] (unknown [24.6.159.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8978050A84 for ; Fri, 24 Jan 2014 12:49:11 -0500 (EST)
Message-ID: <52E2A793.4090605@nextbeacon.com>
Date: Fri, 24 Jan 2014 09:49:07 -0800
From: Steve Waldbusser 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: mib-doctors@ietf.org
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 140124-0, 01/24/2014), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 17:49:15 -0000

I think it's great to have summary/overview tables like this up front to 
help people visualize the MIB.

I think the 'notify' flag could be misleading. It implies that notify 
access could be removed and that it's a separate concept from read access.

Steve

On 1/24/2014 3:14 AM, Juergen Quittek wrote:
> Hi Benoit,
> I have not seen any text documenting this format in a standards document, yet.
> The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values:
>      "not-accessible"->"---"
>      "accessible-for-notify"->"--n"
>      "read-only"->"r-n"
>      "read-write"->"rwn"
>      "read-create"->"rwn" (why not "rcn"?)
> Juergen
>
>> -----Original Message-----
>> From: Benoit Claise [mailto:bclaise@cisco.com]
>> Sent: Freitag, 24. Januar 2014 11:51
>> To: MIB Doctors (E-mail)
>> Cc: draft-ietf-eman-energy-aware-mib.all@tools.ietf.org; draft-ietf-eman-
>> energy-monitoring-mib@tools.ietf.org
>> Subject: rwn for MIB specifications?
>>
>> Dear all,
>>
>> Is there some standard text to explain what  "rwn" (read, write, notify) for
>> object trees mean?
>> For example:
>>
>>    +- eoTable(2)
>>             |
>>             +- eoEntry(1) [entPhysicalIndex]
>>             |  |
>>             |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
>>             |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
>>             |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
>>             |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
>>             |  +-- r-n InetAddressType              eoMgmtAddressType(5)
>>             |  +-- r-n InetAddress                  eoMgmtAddress(6)
>>             |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
>>             |  +-- rwn SnmpAdminString              eoDomainName(8)
>>             |  +-- rwn SnmpAdminString              eoRoleDescription(9)
>>             |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
>>             |  +-- rwn Integer32                    eoImportance(11)
>>             |  +-- r-n INTEGER                      eoPowerCategory(12)
>>             |  +-- rwn SnmpAdminString              eoAlternateKey(13)
>>             |  +-- r-n INTEGER                   eoPowerInterfaceType(14)
>>
>> Regards, Benoit
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors


From j.schoenwaelder@jacobs-university.de  Fri Jan 24 10:37:18 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8561A00E6 for ; Fri, 24 Jan 2014 10:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 QAlLKkkJreI9 for ; Fri, 24 Jan 2014 10:37:16 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 579D21A00E3 for ; Fri, 24 Jan 2014 10:37:16 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E261220050; Fri, 24 Jan 2014 19:37:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HCKhoSrjI39N; Fri, 24 Jan 2014 19:37:14 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 619EF2004B; Fri, 24 Jan 2014 19:37:14 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id CCB872ACD9CD; Fri, 24 Jan 2014 19:37:11 +0100 (CET)
Date: Fri, 24 Jan 2014 19:37:11 +0100
From: Juergen Schoenwaelder 
To: Steve Waldbusser 
Message-ID: <20140124183711.GA63456@elstar.local>
Mail-Followup-To: Steve Waldbusser , mib-doctors@ietf.org
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <52E2A793.4090605@nextbeacon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52E2A793.4090605@nextbeacon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: mib-doctors@ietf.org
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 18:37:18 -0000

On Fri, Jan 24, 2014 at 09:49:07AM -0800, Steve Waldbusser wrote:
> I think it's great to have summary/overview tables like this up
> front to help people visualize the MIB.
> 
> I think the 'notify' flag could be misleading. It implies that
> notify access could be removed and that it's a separate concept from
> read access.

The n flag allows to represent accessible-for-notify: --n

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From waldbusser@nextbeacon.com  Fri Jan 24 10:53:39 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404431A0108 for ; Fri, 24 Jan 2014 10:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] 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 M_K60jaCkKvf for ; Fri, 24 Jan 2014 10:53:38 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 305731A0133 for ; Fri, 24 Jan 2014 10:53:36 -0800 (PST)
Received: from [127.0.0.1] (unknown [24.6.159.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B546250AB9 for ; Fri, 24 Jan 2014 13:53:34 -0500 (EST)
Message-ID: <52E2B6AD.2040409@nextbeacon.com>
Date: Fri, 24 Jan 2014 10:53:33 -0800
From: Steve Waldbusser 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: mib-doctors@ietf.org
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <52E2A793.4090605@nextbeacon.com> <20140124183711.GA63456@elstar.local>
In-Reply-To: <20140124183711.GA63456@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 140124-1, 01/24/2014), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 18:53:39 -0000

On 1/24/2014 10:37 AM, Juergen Schoenwaelder wrote:
> On Fri, Jan 24, 2014 at 09:49:07AM -0800, Steve Waldbusser wrote:
>> I think it's great to have summary/overview tables like this up
>> front to help people visualize the MIB.
>>
>> I think the 'notify' flag could be misleading. It implies that
>> notify access could be removed and that it's a separate concept from
>> read access.
> The n flag allows to represent accessible-for-notify: --n

Yes, I understand that. It's just a poor way to denote it because it is 
not, in fact, independent of read access. For example r-- can never 
happen. Having the extra flag implies it can happen. I don't want people 
thinking it could possible make protocol sense to have an object that 
could be read but couldn't be included in a notification.

We could delete the last flag and have:
    "not-accessible"->"---"
    "accessible-for-notify"->"n-"
    "read-only"->"r-"
    "read-write"->"rw"
    "read-create"->"rc"

Steve


From randy_presuhn@mindspring.com  Fri Jan 24 10:59:38 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76E81A0175; Fri, 24 Jan 2014 10:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 O23TjXYSv2rx; Fri, 24 Jan 2014 10:59:37 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 849E41A009A; Fri, 24 Jan 2014 10:59:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mtqqX7kf9gTDIYmHRsqtbQNi6YvnWCBVzErBNQJWdT+YNYvXII+bIEZgOJ/Fq/lJ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.30.226.130] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W6lyO-0007cB-W4; Fri, 24 Jan 2014 13:59:25 -0500
Message-ID: <00c501cf1936$e4f19640$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: "Thomas Nadeau" , "Benoit Claise" 
References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com> <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com>
Date: Fri, 24 Jan 2014 11:02:55 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc8ff9cbdec71f7635f8ad52d7dca20bb0350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.30.226.130
Cc: "MIB Doctors \(E-mail\)" , eman mailing list 
Subject: Re: [MIB-DOCTORS] MIB Doctor Review ofdraft-ietf-eman-energy-aware-mib-13
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 18:59:38 -0000

Hi -

> From: "Thomas Nadeau" 
> To: "Benoit Claise" 
> Cc: "MIB Doctors (E-mail)" ; "eman mailing list" 
> Sent: Friday, January 24, 2014 7:24 AM
> Subject: Re: [MIB-DOCTORS] MIB Doctor Review ofdraft-ietf-eman-energy-aware-mib-13
...
> That is the kicker - make sure its a UTF-8 encoding specified
> in the description. Right now it reads like a free-form string is
> ok unless you go to the trouble of looking up the reference below. 
...
> Type SnmpAdminString

I don't think it makes much sense for an OBJECT-TYPE making use of
a TEXTUAL-CONVENTION to repeat material from the DESCRIPTION
of the latter.  That really defeats one of the motivations for using TEXTUAL-
CONVENTIONs in the first place.

However, there's another problem, one particularly relevant for INDEX
objects:  SnmpAdminString is arguably under-specified in that it does
not specify the normalization form.  If one wants to find information using
a user-entered index value without having to go poking about in multiple
places in the table (alternate "spellings" if you will), this matters.

Randy


From tnadeau@lucidvision.com  Fri Jan 24 13:24:35 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623DA1A013C; Fri, 24 Jan 2014 13:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.862
X-Spam-Level: *
X-Spam-Status: No, score=1.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_ASCII_ART_SPACINGc=0.833, FRT_LITTLE=1.555, RP_MATCHES_RCVD=-0.535, T_FRT_LITTLE=0.01] 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 3-g2gs2zQUq3; Fri, 24 Jan 2014 13:24:28 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D85DF1A0161; Fri, 24 Jan 2014 13:24:27 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CEEEA26C8173; Fri, 24 Jan 2014 16:24:25 -0500 (EST)
From: Thomas Nadeau 
Content-Type: multipart/signed; boundary="Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Fri, 24 Jan 2014 16:24:24 -0500
Message-Id: 
To: draft-ietf-eman-battery-mib@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Cc: "MIB Doctors \(E-mail\)" , eman mailing list 
Subject: [MIB-DOCTORS] MIB-Doctor Review of draft-ietf-eman-battery-mib-11
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 21:24:35 -0000

--Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



	I reviewed this draft as part of the MIB Doctor review on =
Friday, January 24, 2014.
In general the MIB is in good shape. I have some questions/comments =
inline begin with TOM:

   General Comments on the draft:

   1) My run of id-nits produced no errors and a few warnings that can =
be ignored.

   2) In general, please go through the MIB modules and verify that the =
Integer32 values are indeed ok to be negative values or change them to =
Unsigned. For example, there are many instances where you used Integer32 =
for things like watts or amps where negative values do not make sense, =
to me at least.=20

   3)  There were no warnings or errors in the smilint run.


[server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 =
./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB =
./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB =
./IANA-POWERSTATE-SET-MIB ./ENERGY-OBJECT-MIB ./POWER-ATTRIBTUES-MIB =
./BATTERY-MIB
./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' =
is already loaded, aborting parser on this file
./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be =
imported from module `SNMPv2-SMI'
./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: =
identifier `snmpEngineID' differs from `SnmpEngineID' only in case
./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous =
definition of `SnmpEngineID'
./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 =
instead of INTEGER in SMIv2
./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used
./IANA-POWERSTATE-SET-MIB:39: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./IANA-POWERSTATE-SET-MIB:4: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used
./ENERGY-OBJECT-MIB:111: [1] {object-identifier-unknown} unknown object =
identifier label `energyMIB'
./ENERGY-OBJECT-MIB:620: [5] {index-element-accessible} warning: index =
element `eoEnergyParametersIndex' of row `eoEnergyParametersEntry' =
should be not-accessible in SMIv2 MIB
./ENERGY-OBJECT-MIB:7: [5] {import-unused} warning: identifier `mib-2' =
imported from module `SNMPv2-SMI' is never used
./ENERGY-OBJECT-MIB:10: [5] {import-unused} warning: identifier =
`DisplayString' imported from module `SNMPv2-TC' is never used
./POWER-ATTRIBTUES-MIB:111: [1] {object-identifier-unknown} unknown =
object identifier label `energyMIB'
./POWER-ATTRIBTUES-MIB:6: [5] {import-unused} warning: identifier =
`mib-2' imported from module `SNMPv2-SMI' is never used
./POWER-ATTRIBTUES-MIB:14: [5] {import-unused} warning: identifier =
`OwnerString' imported from module `RMON-MIB' is never use



                                                                       =20=

Network Working Group                                         J. Quittek
Internet-Draft                                                 R. Winter
Intended status: Standards Track                                T. Dietz
Expires: July 11, 2014                                   NEC Europe Ltd.
                                                         January 7, 2014


          Definition of Managed Objects for Battery Monitoring
                     draft-ietf-eman-battery-mib-11

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines managed objects that provide information on
   the status of batteries in managed devices.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 11, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Quittek, et al.           Expires July 11, 2014                 [Page 1]
=20
Internet-Draft                 Battery MIB                  January 2014


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  The Internet-Standard Management Framework . . . . . . . . . .  4

   3.  Design of the Battery MIB Module . . . . . . . . . . . . . . .  5
     3.1.  MIB Module Structure . . . . . . . . . . . . . . . . . . .  5
     3.2.  Battery Technologies . . . . . . . . . . . . . . . . . . .  7
     3.3.  Battery Identification . . . . . . . . . . . . . . . . . .  8
     3.4.  Charging Cycles  . . . . . . . . . . . . . . . . . . . . .  8

   4.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  8

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
     6.1.  SMI Object Identifier Registration . . . . . . . . . . . . 31
     6.2.  Battery Technology Registration  . . . . . . . . . . . . . 31

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 32

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
























Quittek, et al.           Expires July 11, 2014                 [Page 2]
=20
Internet-Draft                 Battery MIB                  January 2014


1.  Introduction

   Today, more and more managed devices contain batteries that supply
   them with power when disconnected from electrical power distribution
   grids.  Common examples are nomadic and mobile devices, such as
   notebook computers, netbooks, and smart phones.  The status of
   batteries in such a device, particularly the charging status is
   typically controlled by automatic functions that act locally on the
   device and manually by users of the device.

   In addition to this, there is a need to monitor battery status of
   these devices by network management systems.  This document defines a
   portion of the Management Information Base (MIB) that provides a
   means for monitoring batteries in or attached to managed devices.
   The Battery MIB module defined in Section 4 meets the requirements
   for monitoring the status of batteries specified in RFC 6988
   [RFC6988].

   The Battery MIB module provides for monitoring the battery status.
   According to the framework for energy management
   [I-D.ietf-eman-framework] it is an Energy Managed Object, and thus,
   MIB modules such as the Power and Energy Monitoring MIB
   [I-D.ietf-eman-energy-monitoring-mib] could in principle be
   implemented for batteries.  The Battery MIB extends the more generic
   aspects of energy management by adding battery-specific information.
   Amongst other things, the Battery MIB enables the monitoring of:

   o  the current charge of a battery,
   o  the age of a battery (charging cycles),
   o  the state of a battery (e.g. being re-charged),
   o  last usage of a battery,
   o  maximum energy provided by a battery (remaining and total
      capacity).

   Further, means are provided for battery-powered devices to send
   notifications when the current battery charge has dropped below a
   certain threshold to inform the management system of needed
   replacement.  The same applies to the age of a battery.

   Many battery-driven devices have existing instrumentation for
   monitoring the battery status, because this is already needed for
   local control of the battery by the device.  This reduces the effort
   for implementing the managed objects defined in this document.  For
   many devices only additional software will be needed but no
   additional hardware instrumentation for battery monitoring.

   Since there are a lot of devices in use that contain more than one
   battery, means for battery monitoring defined in this document



Quittek, et al.           Expires July 11, 2014                 [Page 3]
=20
Internet-Draft                 Battery MIB                  January 2014


   support addressing multiple batteries within a single device.  Also,
   batteries today often come in packages that can include
   identification and might contain additional hardware and firmware.
   The former allows tracing a battery and allows continuous monitoring
   even if the battery is e.g. installed in another device.  The
   firmware version is useful information as the battery behavior might
   be different for different firmware versions.

   Not explicitly in scope of definitions in this document are very
   small backup batteries, such as for example, batteries used on PC
   motherboard to run the clock circuit and retain configuration memory
   while the system is turned off.  Other means may be required for
   reporting on these batteries.  However, the MIB module defined in
   Section 3.1 can be used for this purpose.

   A traditional type of managed device containing batteries is an
   Uninterruptible Power Supply (UPS) system; these supply other devices
   with electrical energy when the main power supply fails.  There is
   already a MIB module for managing UPS systems defined in RFC 1628
   [RFC1628].  The UPS MIB module includes managed objects for
   monitoring the batteries contained in an UPS system.  However, the
   information provided by the UPS MIB objects is limited and tailored
   the particular needs of UPS systems.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].


2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies MIB
   modules that are compliant to the SMIv2, which is described in STD
   58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC
   2580 [RFC2580].







Quittek, et al.           Expires July 11, 2014                 [Page 4]
=20
Internet-Draft                 Battery MIB                  January 2014


3.  Design of the Battery MIB Module

3.1.  MIB Module Structure

   The Battery MIB module defined in this document defines objects for
   reporting information about batteries.  All managed objects providing
   information of the status of a battery are contained in a single
   table called batteryTable.  The batteryTable contains one conceptual
   row per battery.

   Batteries are indexed by the entPhysicalIndex of the entPhysicalTable
   defined in the ENTITY-MIB module [RFC6933].  An implementation of the
   ENTITY-MIB module complying with the entity4CRCompliance MODULE-
   COMPLIANCE statement is required for compliant implementations of the
   BATTERY-MIB module.

   If batteries are replaced with the replacing battery using the same
   physical connector as the replaced battery had used, then the
   replacing battery SHOULD be indexed with the same value of object
   entPhysicalIndex as the replaced battery.

   The kind of entity in the entPhysicalTable of the Entity MIB module
   is indicated by the value of enumeration object entPhysicalClass.
   All batteries SHOULD have the value of object entPhysicalClass set to
   battery(14) in their row of the entPhysicalTable.

   The batteryTable contains three groups of objects.  The first group
   (OIDs ending with 1-10) provides information on static properties of
   the battery.  The second group of objects (OIDs ending with 11-18)
   provides information on the current battery state, if it is charging
   or discharging, how much it is charged, its remaining capacity, the
   number of experienced charging cycles, etc.



















Quittek, et al.           Expires July 11, 2014                 [Page 5]
=20
Internet-Draft                 Battery MIB                  January 2014


      batteryTable(1)
      +--batteryEntry(1) [entPhysicalIndex]
         +-- r-n SnmpAdminString batteryIdentifier(1)
         +-- r-n SnmpAdminString batteryFirmwareVersion(2)
         +-- r-n Enumeration     batteryType(3)
         +-- r-n Unsigned32      batteryTechnology(4)
         +-- r-n Unsigned32      batteryDesignVoltage(5)
         +-- r-n Unsigned32      batteryNumberOfCells(6)
         +-- r-n Unsigned32      batteryDesignCapacity(7)
         +-- r-n Unsigned32      batteryMaxChargingCurrent(8)
         +-- r-n Unsigned32      batteryTrickleChargingCurrent(9)
         +-- r-n Unsigned32      batteryActualCapacity(10)
         +-- r-n Unsigned32      batteryChargingCycleCount(11)
         +-- r-n DateAndTime     batteryLastChargingCycleTime(12)
         +-- r-n Enumeration     batteryChargingOperState(13)
         +-- rwn Enumeration     batteryChargingAdminState(14)
         +-- r-n Unsigned32      batteryActualCharge(15)
         +-- r-n Unsigned32      batteryActualVoltage(16)
         +-- r-n Integer32       batteryActualCurrent(17)
         +-- r-n Integer32       batteryTemperature(18)
         +-- r-n SnmpAdminString batteryCellIdentifier(19)
         +-- rwn Unsigned32      batteryAlarmLowCharge(20)
         +-- rwn Unsigned32      batteryAlarmLowVoltage(21)
         +-- rwn Unsigned32      batteryAlarmLowCapacity(22)
         +-- rwn Unsigned32      batteryAlarmHighCycleCount(23)
         +-- rwn Integer32       batteryAlarmHighTemperature(24)
         +-- rwn Integer32       batteryAlarmLowTemperature(25)

   The third group of objects in this table (OIDs ending with 20-25)
   indicates thresholds which can be used to raise an alarm if a
   property of the battery exceeds one of them.  Raising an alarm may
   include sending a notification.

   The Battery MIB defines seven notifications for indicating

   1.  a battery charging state change that was not triggered by writing
       to object batteryChargingAdminState,
   2.  a low battery charging state,
   3.  a critical battery that cannot be used anymore for power supply,
   4.  an aged battery that may need to be replaced,
   5.  a battery exceed a temperature threshold,
   6.  a battery that has been connected,
   7.  disconnection of one or more batteries.

   Notifications 2.-5. can use object batteryCellIdentifier to indicate
   a specific cell or a set of cells within the battery that have
   triggered the notification.




Quittek, et al.           Expires July 11, 2014                 [Page 6]
=20
Internet-Draft                 Battery MIB                  January 2014


3.2.  Battery Technologies

   Static information in the batteryTable includes battery type and
   technology.  The battery type distinguishes primary (not
   rechargeable) batteries from rechargeable (secondary) batteries and
   capacitors.  The battery technology describes the actual technology
   of a battery, which typically is a chemical technology.

   Since battery technologies are subject of intensive research and
   widely used technologies are often replaced by successor technologies
   within an few years, the list of battery technologies was not chosen
   as a fixed list.  Instead, IANA has created a registry for battery
   technologies at http://www.iana.org/assignments/eman where numbers
   are assigned to battery technologies (TBD).

   The table below shows battery technologies known today that are in
   commercial use with the numbers assigned to them by IANA.  New
   entries can be added to the IANA registry if new technologies are
   developed or if missing technologies are identified.  Note that there
   exists a huge number of battery types that are not listed in the IANA
   registry.  Many of them are experimental or cannot be used in an
   economically useful way.  New entries should be added to the IANA
   registry only if the respective technologies are in commercial use
   and relevant to standardized battery monitoring over the Internet.

      +----------------------------+----------+
      | battery technology         | assigned |
      |                            |  number  |
      +----------------------------+----------+
      | Unknown                    |        1 |
      | Other                      |        2 |
      | Zinc-carbon                |        3 |
      | Zinc chloride              |        4 |
      | Nickel oxyhydroxide        |        5 |
      | Lithium-copper oxide       |        6 |
      | Lithium-iron disulfide     |        7 |
      | Lithium-manganese dioxide  |        8 |
      | Zinc-air                   |        9 |
      | Silver oxide               |       10 |
      | Alkaline                   |       11 |
      | Lead acid                  |       12 |
      | Nickel-cadmium             |       13 |
      | Nickel-metal hybride       |       14 |
      | Nickel-zinc                |       15 |
      | Lithium-ion                |       16 |
      | Lithium polymer            |       17 |
      | Double layer capacitor     |       18 |
      +----------------------------+----------+



Quittek, et al.           Expires July 11, 2014                 [Page 7]
=20
Internet-Draft                 Battery MIB                  January 2014


3.3.  Battery Identification

   There are two identifiers to be used: The entPhysicalUUID defined in
   the ENTITY-MIB [RFC6933] module and the batteryIdentifier defined in
   this module.  A battery is linked to an entPhysicalUUID through the
   shared entPhysicalIndex.

   The batteryIdentifier uniquely identifies the battery itself while
   the entPhysicalUUID identifies the slot of the device in which the
   battery is (currently) contained.  For a non-replaceable battery both
   identifiers are always linked to the same physical battery.  But for
   batteries that can be replaced, the identifiers have different
   functions.

   The entPhysicalUUID is always the same for a certain battery slot of
   a containing device even if the contained battery is replaced by
   another one.  The batteryIdentifier is a representation of the
   battery identifier set by the battery manufacturer.  It is tied to
   the battery and usually cannot be changed.

   Many manufacturers deliver not just plain batteries but battery
   packages including additional hardware and firmware.  Typically,
   these modules include an battery identifier that can by retrieved by
   a device in which a battery has been installed.  The value of the
   object batteryIdentifier is an exact representation of this
   identifier.  The batteryIdentifier is useful when batteries are
   removed and re-installed in the same device or in other devices.
   Then the device or the network management system can trace batteries
   and achieve continuity of battery monitoring.

3.4.  Charging Cycles

   The lifetime of a battery can be approximated using the measure of
   charging cycles.  A commonly used definition of a charging cycle is
   the amount of discharge equal to the design (or nominal) capacity of
   the battery [SBS].  This means that a single charging cycle may
   include several steps of partial charging and discharging until the
   amount of discharging has reached the design capacity of the battery.
   After that the next charging cycle immediately starts.


4.  Definitions

   BATTERY-MIB DEFINITIONS ::=3D BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       mib-2, Integer32, Unsigned32



Quittek, et al.           Expires July 11, 2014                 [Page 8]
=20
Internet-Draft                 Battery MIB                  January 2014


           FROM SNMPv2-SMI                                -- RFC2578
       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB                        -- RFC3411
       DateAndTime
           FROM SNMPv2-TC                                 -- RFC2579
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
           FROM SNMPv2-CONF                               -- RFC2580
       entPhysicalIndex
           FROM ENTITY-MIB                                -- RFC6933
       Unsigned64TC
              FROM APPLICATION-MIB;                       -- RFC2564

   batteryMIB MODULE-IDENTITY
       LAST-UPDATED "201401071200Z"         -- 07 January 2014
       ORGANIZATION "IETF EMAN Working Group"
       CONTACT-INFO
           "General Discussion: eman@ietf.org
           To Subscribe: http://www.ietf.org/mailman/listinfo/eman
           Archive: http://www.ietf.org/mail-archive/web/eman

           Editor:
             Juergen Quittek
             NEC Europe Ltd.
             NEC Laboratories Europe
             Kurfuersten-Anlage 36
             69115 Heidelberg
             Germany
             Tel: +49 6221 4342-115
             Email: quittek@neclab.eu"

       DESCRIPTION
           "This MIB module defines a set of objects for monitoring
           batteries of networked devices and of their components.

           Copyright (c) 2010 IETF Trust and the persons identified as
           authors of the code.  All rights reserved.

           Redistribution and use in source and binary forms, with or
           without modification, is permitted pursuant to, and subject
           to the license terms contained in, the Simplified BSD
           License set forth in Section 4.c of the IETF Trust's Legal
           Provisions Relating to IETF Documents
           (http://trustee.ietf.org/license-info).

           This version of this MIB module is part of RFC yyyy; see
           the RFC itself for full legal notices."
   -- replace yyyy with actual RFC number & remove this notice




Quittek, et al.           Expires July 11, 2014                 [Page 9]
=20
Internet-Draft                 Battery MIB                  January 2014


   --  Revision history

       REVISION "201401071200Z"         -- 07 January 2014
       DESCRIPTION
           "Initial version, published as RFC yyyy."
   -- replace yyyy with actual RFC number & remove this notice

       ::=3D { mib-2 zzz }
   -- zzz to be assigned by IANA.

   --******************************************************************
   -- Top Level Structure of the MIB module
   --******************************************************************

   batteryNotifications OBJECT IDENTIFIER ::=3D { batteryMIB 0 }
   batteryObjects       OBJECT IDENTIFIER ::=3D { batteryMIB 1 }
   batteryConformance   OBJECT IDENTIFIER ::=3D { batteryMIB 2 }

   --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   -- 1. Object Definitions
   --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   --------------------------------------------------------------------
   -- 1.1. Battery Table
   --------------------------------------------------------------------
   batteryTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF BatteryEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table provides information on batteries.  It contains
           one conceptual row per battery.

TOM: Is this a set of batteries per managed device?

           Batteries are indexed by the entPhysicalIndex of the
           entPhysicalTable defined in the ENTITY-MIB (RFC6933).

           For implementations of the BATTERY-MIB an implementation of
           the ENTITY-MIB complying with the entity4CRCompliance
           MODULE-COMPLIANCE statement of the ENTITY-MIB is required.

           If batteries are replaced with the replacing battery using
           the same physical connector as the replaced battery had
           used, then the replacing battery SHOULD be indexed with the
           same value of object entPhysicalIndex as the replaced
           battery."
       ::=3D { batteryObjects 1 }

   batteryEntry OBJECT-TYPE



Quittek, et al.           Expires July 11, 2014                [Page 10]
=20
Internet-Draft                 Battery MIB                  January 2014


       SYNTAX      BatteryEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry providing information on a battery."
       INDEX  { entPhysicalIndex }
       ::=3D { batteryTable 1 }

   BatteryEntry ::=3D
       SEQUENCE {
          batteryIdentifier               SnmpAdminString,
          batteryFirmwareVersion          SnmpAdminString,
          batteryType                     INTEGER,
          batteryTechnology               Unsigned32,
          batteryDesignVoltage            Unsigned32,
          batteryNumberOfCells            Unsigned32,
          batteryDesignCapacity           Unsigned32,
          batteryMaxChargingCurrent       Unsigned32,
          batteryTrickleChargingCurrent   Unsigned32,
          batteryActualCapacity           Unsigned32,
          batteryChargingCycleCount       Unsigned32,
          batteryLastChargingCycleTime    DateAndTime,
          batteryChargingOperState        INTEGER,
          batteryChargingAdminState       INTEGER,
          batteryActualCharge             Unsigned64TC,
          batteryActualVoltage            Unsigned32,
          batteryActualCurrent            Integer32,
          batteryTemperature              Integer32,
          batteryCellIdentifier           SnmpAdminString,
          batteryAlarmLowCharge           Unsigned32,
          batteryAlarmLowVoltage          Unsigned32,
          batteryAlarmLowCapacity         Unsigned32,
          batteryAlarmHighCycleCount      Unsigned32,
          batteryAlarmHighTemperature     Integer32,
          batteryAlarmLowTemperature      Integer32
       }

   batteryIdentifier OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object contains an identifier for the battery.

           Many manufacturers deliver not only simple batteries but
           battery packages including additional hardware and firmware.
           Typically, these modules include an identifier that can be
           retrieved by a device in which a battery has been installed.



Quittek, et al.           Expires July 11, 2014                [Page 11]
=20
Internet-Draft                 Battery MIB                  January 2014


           The identifier is useful when batteries are removed and
           re-installed in the same or other devices. Then the device
           or the network management system can trace batteries and
           achieve continuity of battery monitoring.

           If the battery identifier cannot be represented using the
           ISO/IEC IS 10646-1 character set, then a hexadecimal
           encoding of a binary representation of the battery
           identifier must be used.

           The value of this object must be an empty string if there
           is no battery identifier or if the battery identifier is
           unknown."
       ::=3D { batteryEntry 1 }

   batteryFirmwareVersion OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the version number of the firmware
           that is included in a battery module.

           Many manufacturers deliver not pure batteries but battery
           packages including additional hardware and firmware.

           Since the behavior of the battery may change with the
           firmware, it may be useful to retrieve the firmware version
           number.

           The value of this object must be an empty string if there
           is no firmware or if the version number of the firmware is
           unknown."
       ::=3D { batteryEntry 2 }

   batteryType OBJECT-TYPE
       SYNTAX      INTEGER {
                       unknown(1),
                       other(2),
                       primary(3),
                       rechargeable(4),
                       capacitor(5)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the type of battery.
           It distinguishes between primary (not rechargeable)



Quittek, et al.           Expires July 11, 2014                [Page 12]
=20
Internet-Draft                 Battery MIB                  January 2014


           batteries, rechargeable (secondary) batteries and capacitors
           which are not really batteries but often used in the same
           way as a battery.

           The value other(2) can be used if the battery type is known
           but none of the ones above.  Value unknown(1) is to be used
           if the type of battery cannot be determined."
       ::=3D { batteryEntry 3 }

   batteryTechnology OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the technology used by the battery.
           Numbers identifying battery types are registered at IANA.
           A current list of assignments can be found at
           .

           Value 0 (unknown) MUST be used if the type of battery
           cannot be determined.

           Value 1 (other) can be used if the battery type is known
           but not one of the types already registered at IANA."
       ::=3D { batteryEntry 4 }

   batteryDesignVoltage OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "millivolt"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the design (or nominal) voltage of the
           battery in units of millivolt (mV).

           Note that the design voltage is a constant value and
           typically different from the actual voltage of the battery.

           A value of 0 indicates that the design voltage is unknown."
       ::=3D { batteryEntry 5 }

   batteryNumberOfCells OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the number of cells contained in the
           battery.



Quittek, et al.           Expires July 11, 2014                [Page 13]
=20
Internet-Draft                 Battery MIB                  January 2014


           A value of 0 indicates that the number of cells is unknown."
       ::=3D { batteryEntry 6 }

   batteryDesignCapacity OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "milliampere hours"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the design (or nominal) capacity of
           the battery in units of milliampere hours (mAh).

           Note that the design capacity is a constant value and
           typically different from the actual capacity of the battery.
           Usually, this is a value provided by the manufacturer of the
           battery.

           A value of 0 indicates that the design capacity is
           unknown."
       ::=3D { batteryEntry 7 }

   batteryMaxChargingCurrent OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "milliampere"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the maximal current to be used for
           charging the battery in units of milliampere (mA).

           Note that the maximal charging current may not lead to
           optimal charge of the battery and that some batteries can
           only be charged with the maximal current for a limited
           amount of time.

           A value of 0 indicates that the maximal charging current is
           unknown."
       ::=3D { batteryEntry 8 }

   batteryTrickleChargingCurrent OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "milliampere"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the recommended current to be used for
           trickle charging the battery in units of milliampere (mA).




Quittek, et al.           Expires July 11, 2014                [Page 14]
=20
Internet-Draft                 Battery MIB                  January 2014


           Typically, this is a value recommended by the manufacturer
           of the battery or by the manufacturer of the charging
           circuit.

           A value of 0 indicates that the recommended trickle charging
           current is unknown."
       ::=3D { batteryEntry 9 }

   batteryActualCapacity OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "milliampere hours"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the actual capacity of the
           battery in units of milliampere hours (mAh).

           Typically, the actual capacity of a battery decreases
           with time and with usage of the battery. It is usually
           lower than the design capacity

           Note that the actual capacity needs to be measured and is
           typically an estimate based on observed discharging and
           charging cycles of the battery.

           A value of 'ffffffff'H indicates that the actual capacity
           cannot be determined."
       ::=3D { batteryEntry 10 }

   batteryChargingCycleCount OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the number of completed charging
           cycles that the battery underwent. In line with the
           Smart Battery Data Specification Revision 1.1, a charging
           cycle is defined as the process of discharging the battery
           by a total amount equal to the battery design capacity as
           given by object batteryDesignCapacity. A charging cycle
           may include several steps of charging and discharging the
           battery until the discharging amount given by
           batteryDesignCapacity has been reached. As soon as a
           charging cycle has been completed the next one starts
           immediately independent of the battery's current charge at
           the end of the cycle.

           For batteries of type primary(1) the value of this object is



Quittek, et al.           Expires July 11, 2014                [Page 15]
=20
Internet-Draft                 Battery MIB                  January 2014


           always 0.

           A value of 'ffffffff'H indicates that the number of charging
           cycles cannot be determined."
       ::=3D { batteryEntry 11 }

   batteryLastChargingCycleTime OBJECT-TYPE
       SYNTAX      DateAndTime
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The date and time of the last charging cycle.  The value
           '0000000000000000'H is returned if the battery has not been
           charged yet or if the last charging time cannot be
           determined.

           For batteries of type primary(1) the value of this object is
           always '0000000000000000'H."
       ::=3D { batteryEntry 12 }

   batteryChargingOperState OBJECT-TYPE
       SYNTAX      INTEGER {
                       unknown(1),
                       charging(2),
                       fastCharging(3),
                       maintainingCharge(4),
                       noCharging(5),
                       discharging(6)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the current charging state of the
           battery.

           Value unknown(1) indicates that the charging state of the
           battery cannot be determined.

           Value charging(2) indicates that the battery is being
           charged in a way that the charge of the battery increases.

           Value fastCharging(3) indicated that the battery is being
           charged rapidly, i.e. faster than in the charging(2) state.
           If multiple fast charging states exist, all of these
           states are indicated by fastCharging(3).

           Value maintainingCharge(4) indicates that the battery is
           being charged with a low current that compensates



Quittek, et al.           Expires July 11, 2014                [Page 16]
=20
Internet-Draft                 Battery MIB                  January 2014


           self-discharging. This includes trickle charging, float
           charging and other methods for maintaining the current
           charge of a battery.

           Value noCharging(5) indicates that the battery is not being
           charged or discharged by electric current between the
           battery and electric circuits external to the battery.
           Note that the battery may still be subject to
           self-discharging.

           Value discharging(6) indicates that the battery is being
           discharged and that the charge of the battery decreases."
       ::=3D { batteryEntry 13 }

   batteryChargingAdminState OBJECT-TYPE
       SYNTAX      INTEGER {
                       charging(2),
                       fastCharging(3),
                       maintainingCharge(4),
                       noCharging(5),
                       discharging(6),
                       notSet(7)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The value of this object indicates the desired status of
           the charging state of the battery. The real state is
           indicated by object batteryChargingOperState. See the
           definition of object batteryChargingOperState for a
           description of the values.

           When this object is initialized by an implementation of the
           BATTERY-MIB module, its value is set to notSet(7).

           However, a SET request can only set this object to either
           charging(2), fastCharging(3), maintainingCharge(4),
           noCharging(5), or discharging(6). Attempts to set this
           object to notSet(7) will always fail with an
           'inconsistentValue' error. In case multiple fast charging
           states exist, the battery logic can choose an appropriate
           fast charging state - preferably the fastest.

           When the batteryChargingAdminState object is set, then the
           BATTERY-MIB implementation must try to set the battery
           to the indicated state. The result will be indicated by
           object batteryChargingOperState.




Quittek, et al.           Expires July 11, 2014                [Page 17]
=20
Internet-Draft                 Battery MIB                  January 2014


           Due to operational conditions and limitations of the
           implementation of the BATTERY-MIB module, changing the
           battery status according to a set value of object
           batteryChargingAdminState may not be possible.

           Setting the value of object batteryChargingAdminState
           may result in not changing the state of the battery
           to this value or even in setting the charging state
           to another value. For example, setting
           batteryChargingAdminState to value fastCharging(3) may
           have no effect when the battery logic is not allowing
           fast charging due to temperature constraints."

       ::=3D { batteryEntry 14 }

   batteryActualCharge OBJECT-TYPE
       SYNTAX      Unsigned64TC
       UNITS       "milliampere hours"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the actual charge of the battery
           in units of milliampere hours (mAh).

           Note that the actual charge needs to be measured and is
           typically an estimate based on observed discharging and
           charging cycles of the battery.

           A value of 'ffffffff'H indicates that the actual charge
           cannot be determined."
       ::=3D { batteryEntry 15 }

   batteryActualVoltage OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "millivolt"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the actual voltage of the battery
           in units of millivolt (mV).

           A value of 'ffffffff'H indicates that the actual voltage
           cannot be determined."
       ::=3D { batteryEntry 16 }

   batteryActualCurrent OBJECT-TYPE
       SYNTAX      Integer32
       UNITS       "milliampere"



Quittek, et al.           Expires July 11, 2014                [Page 18]
=20
Internet-Draft                 Battery MIB                  January 2014


       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object provides the actual charging or discharging
           current of the battery in units of milliampere (mA).
           Charging current is represented by positive values,
           discharging current is represented by negative values.

           A value of '7fffffff'H indicates that the actual current
           cannot be determined."
       ::=3D { batteryEntry 17 }

   batteryTemperature OBJECT-TYPE
       SYNTAX      Integer32
       UNITS       "deci-degrees Celsius"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The ambient temperature at or near the battery.

TOM: Is there some spec that defines what "near" means?

           A value of '7fffffff'H indicates that the temperature
           cannot be determined."
       ::=3D { batteryEntry 18 }

   batteryCellIdentifier OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The value of this object identifies one or more cells of a
           battery.  The format of the cell identifier may vary between
           different implementations.  It should uniquely identify one
           or more cells of the indexed battery.

           This object can be used for batteries, such as, for example,
           lithium polymer batteries for which battery controllers
           monitor cells individually.

           This object is used by notifications of type
           batteryLowNotification, batteryTemperatureNotification,
           batteryCriticalNotification, and batteryAgingNotification.
           These notifications can use the value of this object to
           indicate the event that triggered the generation of the
           notification in more details by specifying a single cell
           or a set of cells within the battery which are specifically
           addressed by the notification.

           An example use case for this object is a single cell in a



Quittek, et al.           Expires July 11, 2014                [Page 19]
=20
Internet-Draft                 Battery MIB                  January 2014


           battery that exceeds the temperature indicated by object
           batteryAlarmHighTemperature.  In such a case, a
           batteryTemperatureNotification can be generated that not
           just indicates the battery for which the temperature is
           exceeded but also the particular cell.

           The initial value of this object is the empty string.  The
           value of this object is set at each time a
           batteryLowNotification, a batteryTemperatureNotification,
           a batteryCriticalNotification, or a batteryAgingNotification
           is generated.

           When a notification is generated that does not indicate a
           specific cell or set of cells, the value of this object is
           set to the empty string."
       ::=3D { batteryEntry 19 }

   batteryAlarmLowCharge OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "milliampere hours"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object provides the lower threshold value for object
           batteryActualCharge.  If the value of object
           batteryActualCharge falls below this threshold,
           a low battery alarm will be raised.  The alarm procedure may
           include generating a batteryLowNotification.

           This object should be set to a value such that when the
           batteryLowNotification is generated, the battery is still
           sufficiently charged to keep the device(s) that it powers
           operational for a time long enough to take actions before
           the powered device(s) enter a 'sleep' or 'off' state.

           A value of 0 indicates that no alarm will be raised for any
           value of object batteryActualCharge."
       ::=3D { batteryEntry 20 }

   batteryAlarmLowVoltage OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "millivolt"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object provides the lower threshold value for object
           batteryActualVoltage.  If the value of object
           batteryActualVoltage falls below this threshold,



Quittek, et al.           Expires July 11, 2014                [Page 20]
=20
Internet-Draft                 Battery MIB                  January 2014


           a low battery alarm will be raised.  The alarm procedure may
           include generating a batteryLowNotification.

           This object should be set to a value such that when the
           batteryLowNotification is generated, the battery is still
           sufficiently charged to keep the device(s) that it powers
           operational for a time long enough to take actions before
           the powered device(s) enter a 'sleep' or 'off' state.

           A value of 0 indicates that no alarm will be raised for any
           value of object batteryActualVoltage."
       ::=3D { batteryEntry 21 }

   batteryAlarmLowCapacity OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "milliampere hours"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object provides the lower threshold value for object
           batteryActualCapacity.  If the value of object
           batteryActualCapacity falls below this threshold,
           a battery aging alarm will be raised.  The alarm procedure
           may include generating a batteryAgingNotification.

           A value of 0 indicates that no alarm will be raised for any
           value of object batteryActualCapacity."
       ::=3D { batteryEntry 22 }

   batteryAlarmHighCycleCount OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object provides the upper threshold value for object
           batteryChargingCycleCount.  If the value of object
           batteryChargingCycleCount rises above this threshold,
           a battery aging alarm will be raised.  The alarm procedure
           may include generating a batteryAgingNotification.

           A value of 0 indicates that no alarm will be raised for any
           value of object batteryChargingCycleCount."

TOM: Is there  any sort of holding time period over which an alarm =
should be not emitted? I can imagine a case where a battery is charged, =
discharged, etc... and just goes above and below this threshold causing =
a lot of notifications to be emitted. Another option would be to add =
variable that defines X numebr of notifications per time period.

       ::=3D { batteryEntry 23 }

   batteryAlarmHighTemperature OBJECT-TYPE
       SYNTAX      Integer32
       UNITS       "deci-degrees Celsius"
       MAX-ACCESS  read-write



Quittek, et al.           Expires July 11, 2014                [Page 21]
=20
Internet-Draft                 Battery MIB                  January 2014


       STATUS      current
       DESCRIPTION
           "This object provides the upper threshold value for object
           batteryTemperature.  If the value of object
           batteryTemperature rises above this threshold, a battery
           high temperature alarm will be raised.  The alarm procedure
           may include generating a batteryTemperatureNotification.

           A value of '7fffffff'H indicates that no alarm will be
           raised for any value of object batteryTemperature."
       ::=3D { batteryEntry 24 }

   batteryAlarmLowTemperature OBJECT-TYPE
       SYNTAX      Integer32
       UNITS       "deci-degrees Celsius"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object provides the lower threshold value for object
           batteryTemperature.  If the value of object
           batteryTemperature falls below this threshold, a battery
           low temperature alarm will be raised.  The alarm procedure
           may include generating a batteryTemperatureNotification.

           A value of '7fffffff'H indicates that no alarm will be
           raised for any value of object batteryTemperature."
       ::=3D { batteryEntry 25 }


   --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   -- 2. Notifications
   --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   batteryChargingStateNotification NOTIFICATION-TYPE
       OBJECTS     {
           batteryChargingOperState
       }
       STATUS      current
       DESCRIPTION
           "This notification can be generated when a charging state
           of the battery (indicated by the value of object
           batteryChargingOperState) is triggered by an event other
           than a write action to object batteryChargingAdminState.
           Such an event may, for example, be triggered by a local
           battery controller."
       ::=3D { batteryNotifications 1 }

   batteryLowNotification NOTIFICATION-TYPE



Quittek, et al.           Expires July 11, 2014                [Page 22]
=20
Internet-Draft                 Battery MIB                  January 2014


       OBJECTS     {
           batteryActualCharge,
           batteryActualVoltage,
           batteryCellIdentifier
       }
       STATUS      current
       DESCRIPTION
           "This notification can be generated when the current charge
           (batteryActualCharge) or the current voltage
           (batteryActualVoltage) of the battery falls below a
           threshold defined by object batteryAlarmLowCharge or object
           batteryAlarmLowVoltage, respectively.

           Note that typically, this notification is generated in a
           state where the battery is still sufficiently charged to keep
           the device(s) that it powers operational for some time.
           If the charging state of the battery has become critical,
           i.e., the device(s) powered by the battery must go to a
           'sleep' or 'off' state, then the batteryCriticalNotification
           should be used instead.

           The notification should not be sent again before the current
           voltage or the current charge becomes higher than the
           respective thresholds through charging before falling below
           the thresholds again.

           If the low charge or voltage has been detected for a single
           cell or a set of cells of the battery and not for the entire
           battery, then object batteryCellIdentifier should be set to
           a value that identifies the cell or set of cells.
           Otherwise, the value of object batteryCellIdentifier should
           be set to the empty string when this notification is
           generated."
       ::=3D { batteryNotifications 2 }

   batteryCriticalNotification NOTIFICATION-TYPE
       OBJECTS     {
           batteryActualCharge,
           batteryActualVoltage,
           batteryCellIdentifier
       }
       STATUS      current
       DESCRIPTION
           "This notification can be generated when the current charge
           of the battery falls so low that it cannot provide a
           sufficient power supply function for regular operation
           of the powered device(s). The battery needs to be charged
           before it can be used for regular power supply again. The



Quittek, et al.           Expires July 11, 2014                [Page 23]
=20
Internet-Draft                 Battery MIB                  January 2014


           battery may still provide sufficient power for a 'sleep'
           mode of powered device(s) or for a transition into an 'off'
           mode.

           The notification should not be sent again before the battery
           charge has increased to a non-critical value.

           If the critical state is caused a single cell or a set of
           cells of the battery, then object batteryCellIdentifier
           should be set to a value that identifies the cell or set of
           cells.  Otherwise, the value of object batteryCellIdentifier
           should be set to the empty string when this notification is
           generated."
       ::=3D { batteryNotifications 3 }

   batteryTemperatureNotification NOTIFICATION-TYPE
       OBJECTS     {
           batteryTemperature,
           batteryCellIdentifier
       }
       STATUS      current
       DESCRIPTION
           "This notification can be generated when the measured
           temperature (batteryTemperature) rises above the threshold
           defined by object batteryAlarmHighTemperature or falls
           below the threshold defined by object
           batteryAlarmLowTemperature.

           If the low or high temperature has been detected for a
           single cell or a set of cells of the battery and not for the
           entire battery, then object batteryCellIdentifier should be
           set to a value that identifies the cell or set of cells.
           Otherwise, the value of object batteryCellIdentifier should
           be set to the empty string when this notification is
           generated."
       ::=3D { batteryNotifications 4 }

TOM: The same comment about rate limiting as above. I can see when a =
battery is failing this value could float just about and below this =
value causing numerious notifications to be issued. Have you considered =
such cases?

   batteryAgingNotification NOTIFICATION-TYPE
       OBJECTS     {
           batteryActualCapacity,
           batteryChargingCycleCount,
           batteryCellIdentifier
       }
       STATUS      current
       DESCRIPTION
           "This notification can be generated when the actual
           capacity (batteryActualCapacity) falls below a threshold
           defined by object batteryAlarmLowCapacity



Quittek, et al.           Expires July 11, 2014                [Page 24]
=20
Internet-Draft                 Battery MIB                  January 2014


           or when the charging cycle count of the battery
           (batteryChargingCycleCount) exceeds the threshold defined
           by object batteryAlarmHighCycleCount.

           If the aging has been detected for a single cell or a set of
           cells of the battery and not for the entire battery, then
           object batteryCellIdentifier should be set to a value that
           identifies the cell or set of cells.  Otherwise, the value
           of object batteryCellIdentifier should be set to the empty
           string when this notification is generated."
       ::=3D { batteryNotifications 5 }

   batteryConnectedNotification NOTIFICATION-TYPE
       OBJECTS     {
           batteryIdentifier
       }
       STATUS      current
       DESCRIPTION
           "This notification can be generated when it has been
           detected that a battery has been connected. The battery
           can be identified by the value of object batteryIdentifier
           as well as by the value of index entPhysicalIndex that is
           contained in the OID of object batteryIdentifier."
       ::=3D { batteryNotifications 6 }

   batteryDisconnectedNotification NOTIFICATION-TYPE
       STATUS      current
       DESCRIPTION
           "This notification can be generated when it has been
           detected that one or more batteries have been disconnected."
       ::=3D { batteryNotifications 7 }


   --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   -- 3. Conformance Information
   --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   batteryCompliances OBJECT IDENTIFIER ::=3D { batteryConformance 1 }
   batteryGroups      OBJECT IDENTIFIER ::=3D { batteryConformance 2 }

   --------------------------------------------------------------------
   -- 3.1. Compliance Statements
   --------------------------------------------------------------------

   batteryCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for implementations of the



Quittek, et al.           Expires July 11, 2014                [Page 25]
=20
Internet-Draft                 Battery MIB                  January 2014


           BATTERY-MIB module.

           A compliant implementation MUST implement the objects
           defined in the mandatory groups batteryDescriptionGroup
           and batteryStatusGroup.

           Note that compliance with this compliance
           statement requires compliance with the
           entity4CRCompliance MODULE-COMPLIANCE statement of the
           ENTITY-MIB (RFC6933)."
       MODULE  -- this module
           MANDATORY-GROUPS {
               batteryDescriptionGroup,
               batteryStatusGroup
           }

           GROUP   batteryAlarmThresholdsGroup
           DESCRIPTION
              "A compliant implementation does not have to implement
               the batteryAlarmThresholdsGroup."

           GROUP   batteryNotificationsGroup
           DESCRIPTION
              "A compliant implementation does not have to implement
               the batteryNotificationsGroup."

           GROUP   batteryPerCellNotificationsGroup
           DESCRIPTION
              "A compliant implementation does not have to implement
               the batteryPerCellNotificationsGroup."

           GROUP   batteryAdminGroup
           DESCRIPTION
              "A compliant implementation does not have to implement
               the batteryAdminGroup."

           OBJECT batteryAlarmLowCharge
           MIN-ACCESS  read-only
           DESCRIPTION
               "A compliant implementation is not required
               to support set operations to this object."

           OBJECT batteryAlarmLowVoltage
           MIN-ACCESS  read-only
           DESCRIPTION
               "A compliant implementation is not required
               to support set operations to this object."




Quittek, et al.           Expires July 11, 2014                [Page 26]
=20
Internet-Draft                 Battery MIB                  January 2014


           OBJECT batteryAlarmLowCapacity
           MIN-ACCESS  read-only
           DESCRIPTION
               "A compliant implementation is not required
               to support set operations to this object."

           OBJECT batteryAlarmHighCycleCount
           MIN-ACCESS  read-only
           DESCRIPTION
               "A compliant implementation is not required
               to support set operations to this object."

           OBJECT batteryTemperatureNotification
           MIN-ACCESS  read-only
           DESCRIPTION
               "A compliant implementation is not required
               to support set operations to this object."

       ::=3D { batteryCompliances 1 }

   --------------------------------------------------------------------
   -- 3.2. MIB Grouping
   --------------------------------------------------------------------

   batteryDescriptionGroup OBJECT-GROUP
       OBJECTS {
          batteryIdentifier,
          batteryFirmwareVersion,
          batteryType,
          batteryTechnology,
          batteryDesignVoltage,
          batteryNumberOfCells,
          batteryDesignCapacity,
          batteryMaxChargingCurrent,
          batteryTrickleChargingCurrent
       }
       STATUS      current
       DESCRIPTION
          "A compliant implementation MUST implement the objects
          contained in this group."
       ::=3D { batteryGroups 1 }

   batteryStatusGroup OBJECT-GROUP
       OBJECTS {
          batteryActualCapacity,
          batteryChargingCycleCount,
          batteryLastChargingCycleTime,
          batteryChargingOperState,



Quittek, et al.           Expires July 11, 2014                [Page 27]
=20
Internet-Draft                 Battery MIB                  January 2014


          batteryActualCharge,
          batteryActualVoltage,
          batteryActualCurrent,
          batteryTemperature
       }
       STATUS      current
       DESCRIPTION
          "A compliant implementation MUST implement the objects
          contained in this group."
       ::=3D { batteryGroups 2 }

   batteryAdminGroup OBJECT-GROUP
       OBJECTS {
          batteryChargingAdminState
       }
       STATUS      current
       DESCRIPTION
          "A compliant implementation does not have to implement the
          object contained in this group."
       ::=3D { batteryGroups 3 }

   batteryAlarmThresholdsGroup OBJECT-GROUP
       OBJECTS {
          batteryAlarmLowCharge,
          batteryAlarmLowVoltage,
          batteryAlarmLowCapacity,
          batteryAlarmHighCycleCount,
          batteryAlarmHighTemperature,
          batteryAlarmLowTemperature
       }
       STATUS      current
       DESCRIPTION
          "A compliant implementation does not have to implement the
          objects contained in this group."
       ::=3D { batteryGroups 4 }

   batteryNotificationsGroup NOTIFICATION-GROUP
       NOTIFICATIONS {
          batteryChargingStateNotification,
          batteryLowNotification,
          batteryCriticalNotification,
          batteryAgingNotification,
          batteryTemperatureNotification,
          batteryConnectedNotification,
          batteryDisconnectedNotification
       }
       STATUS      current
       DESCRIPTION



Quittek, et al.           Expires July 11, 2014                [Page 28]
=20
Internet-Draft                 Battery MIB                  January 2014


           "A compliant implementation does not have to implement the
           notifications contained in this group."
       ::=3D { batteryGroups 5 }

   batteryPerCellNotificationsGroup OBJECT-GROUP
       OBJECTS {
          batteryCellIdentifier
       }
       STATUS      current
       DESCRIPTION
           "A compliant implementation does not have to implement the
           object contained in this group."
       ::=3D { batteryGroups 6 }
   END


5.  Security Considerations

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write.  Such objects may be
   considered sensitive or vulnerable in some network environments.  The
   support for SET operations in a non-secure environment without proper
   protection can have a negative effect on network operations.  These
   are the tables and objects and their sensitivity/vulnerability:

   o  batteryChargingAdminState
      Setting the battery charging state can be beneficial for an
      operator for various reasons such as charging batteries when the
      price of electricity is low.  However, setting the charging state
      can be used by an attacker to discharge batteries of devices and
      thereby switching these devices off if they are powered solely by
      batteries.  In particular, if the batteryAlarmLowCharge and
      batteryAlarmLowVoltage can also be set, this attack will go
      unnoticed (i.e. no notifications are sent).

   o  batteryAlarmLowCharge and batteryAlarmLowVoltage
      These objects set the threshold for an alarm to be raised when the
      battery charge or voltage falls below the corresponding one of
      them.  An attacker setting one of these alarm values can switch
      off the alarm by setting it to the 'off' value 0 or modify the
      alarm behavior by setting it to any other value.  The result may
      be loss of data if the battery runs empty without warning to a
      recipient expecting such a notification.

   o  batteryAlarmLowCapacity and batteryAlarmHighCycleCount
      These objects set the threshold for an alarm to be raised when the
      battery becomes older and less performant than required for stable
      operation.  An attacker setting this alarm value can switch off



Quittek, et al.           Expires July 11, 2014                [Page 29]
=20
Internet-Draft                 Battery MIB                  January 2014


      the alarm by setting it to the 'off' value 0 or modify the alarm
      behavior by setting it to any other value.  This may either lead
      to a costly replacement of a working battery or too old or too
      weak batteries being used.  The consequence of the latter could
      e.g. be that a battery cannot provide power long enough between
      two scheduled charging actions causing the powered device to shut
      down and potentially lose data.

   o  batteryAlarmHighTemperature and batteryAlarmLowTemperature
      These objects set thresholds for an alarm to be raised when the
      battery rises above/falls below them.  An attacker setting one of
      these alarm values can switch off these alarms by setting them to
      the 'off' value '7fffffff'H or modify the alarm behavior by
      setting them to any other value.  The result may e.g. be an
      unnecessary shutdown of a device if batteryAlarmHighTemperature is
      set to too low or damage to the device by too high temperatures if
      switched off or set to too high values or by damage to the battery
      when it e.g. is being charged.  Batteries can also be damaged e.g.
      in an attempt to charge them at too low temperatures.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   All potentially sensible or vulnerable objects of this MIB module are
   in the batteryTable.  In general, there are no serious operational
   vulnerabilities foreseen in case of an unauthorized read access to
   this table.  However, privacy issues need to be considered.  It may
   be a trade secret of the operator
   o  how many batteries are installed in a managed node (batteryIndex)
   o  how old these batteries are (batteryActualCapacity and
      batteryChargingCycleCount)
   o  when the next replacement cycle for batteries can be expected
      (batteryAlarmLowCapacity and batteryAlarmHighCycleCount)
   o  what battery type and make are used with which firmware version
      (batteryIdentifier, batteryFirmwareVersion, batteryType, and
      batteryTechnology)

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is allowed to
   access and GET/SET (read/change/create/delete) the objects in this
   MIB module.




Quittek, et al.           Expires July 11, 2014                [Page 30]
=20
Internet-Draft                 Battery MIB                  January 2014


   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to GET or SET (change/create/delete) them.


6.  IANA Considerations

6.1.  SMI Object Identifier Registration

   The Battery MIB module defined in this document uses the following
   IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers
   registry:

             Descriptor        OBJECT IDENTIFIER value
             ----------        -----------------------
             batteryMIB        { mib-2 xxx }

   [NOTE for IANA: Please allocate an object identifier at
   http://www.iana.org/assignments/smi-numbers for object batteryMIB.]

6.2.  Battery Technology Registration

   Object batteryTechnology defined in Section 4 reports battery
   technologies.  Eighteen values for battery technologies have
   initially been defined.  They are listed in a table in Section 3.2.

   For ensuring extensibility of this list, IANA has created a registry
   for battery technologies at http://www.iana.org/assignments/eman and
   filled it with the initial list given in Section 3.2.

   New assignments of numbers for battery technologies will be
   administered by IANA through Expert Review ([RFC5226]).  Experts must
   check for sufficient relevance of a battery technology to be added.

   [NOTE for IANA: Please create a new registry under
   http://www.iana.org/assignments/eman for battery types.  Please fill
   the registry with values from the table in Section 3.2]





Quittek, et al.           Expires July 11, 2014                [Page 31]
=20
Internet-Draft                 Battery MIB                  January 2014


7.  Acknowledgements

   We would like to thank Steven Chew and Bill Mielke for their valuable
   input.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

   [RFC6933]  Bierman, A., Romascanu, D., Quittek, J., and M.
              Chandramouli, "Entity MIB (Version 4)", RFC 6933,
              May 2013.

8.2.  Informative References

   [RFC6988]  Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and
              B. Claise, "Requirements for Energy Management", RFC 6988,
              September 2013.

   [I-D.ietf-eman-framework]
              Parello, J., Claise, B., Schoening, B., and J. Quittek,
              "Energy Management Framework",
              draft-ietf-eman-framework-11 (work in progress),
              October 2013.

   [I-D.ietf-eman-energy-monitoring-mib]
              Chandramouli, M., Schoening, B., Quittek, J., Dietz, T.,
              and B. Claise, "Power and Energy Monitoring MIB",



Quittek, et al.           Expires July 11, 2014                [Page 32]
=20
Internet-Draft                 Battery MIB                  January 2014


              draft-ietf-eman-energy-monitoring-mib-07 (work in
              progress), October 2013.

   [RFC1628]  Case, J., "UPS Management Information Base", RFC 1628,
              May 1994.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

   [SBS]      "Smart Battery Data Specification", Revision 1.1,
              December 1998.


Authors' Addresses

   Juergen Quittek
   NEC Europe Ltd.
   NEC Laboratories Europe
   Network Research Division
   Kurfuersten-Anlage 36
   Heidelberg  69115
   DE

   Phone: +49 6221 4342-115
   Email: quittek@neclab.eu


   Rolf Winter
   NEC Europe Ltd.
   NEC Laboratories Europe
   Network Research Division
   Kurfuersten-Anlage 36
   Heidelberg  69115
   DE

   Phone: +49 6221 4342-121
   Email: Rolf.Winter@neclab.eu













Quittek, et al.           Expires July 11, 2014                [Page 33]
=20
Internet-Draft                 Battery MIB                  January 2014


   Thomas Dietz
   NEC Europe Ltd.
   NEC Laboratories Europe
   Network Research Division
   Kurfuersten-Anlage 36
   Heidelberg  69115
   DE

   Phone: +49 6221 4342-128
   Email: Thomas.Dietz@neclab.eu









































Quittek, et al.           Expires July 11, 2014                [Page 34]


Html markup produced by rfcmarkup 1.106, available from =
http://tools.ietf.org/tools/rfcmarkup/=20

--Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS4toIAAoJEPcO+I7eiUJZPWoP/1VTQokcr+mWtEeV/ZChVuAb
FoDCiNHNRwdUb5eoq+xSM+grhx5QsZ0BeEDf96FiQBUJv6A+axrj0rRsVWDIZPZc
r84+ruDUbpjAnkRoSX5/PmacAnwOTNLrpMAO9tx3Xt+vnJHEVZs74F+ubXhnAXQE
girXby7FQv5Gy/kdF5toHuahfrEg2/sJU/WmejMp3HNKwMAP3y4DT7ObZXWQ998a
L98w11suOtP789NVe+OB+xIL+/dQvQjXIKmdPqPGEwziXtX2Nrc/3h2QuSeEdVU+
Nt0jJ6s1ioVayDGVkBZcZE4cJl5kEl15Oddz/ZOmFQPieeXnRUqvleFWBzgnvWiV
IvIcAZamxk1JIJATPRup6qRm3Zm4PViriFxzb83IVwKd2GiG+SPSHLDd+pUIhQX6
px437Od/7V6BJ5hc2BmJqtX0mDKRf0Fh9/gegxVLeZI+0rM06uKovvI/QUuGAmIm
6O0LuGM8GihBOLmi7h/CyH21VptUEjwfgg3vm9rO1u3/BxHeIuSMx25C3p45UOLt
lX2vJa2qYPMnRnVodVee8m9vSJfKfOaLiYlH0a096XJP7RE5VMwRSZn22KTy2Th0
KiFcFzBiMq3rNJ3d3uXHJKfN69m8cylXN2jtdw6Z8fHJp18TbN37xTmuMAZtTeir
d28mumBXbmPMYfNaJTVR
=kPdp
-----END PGP SIGNATURE-----

--Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8--

From j.schoenwaelder@jacobs-university.de  Fri Jan 24 13:40:34 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D226A1A00CC for ; Fri, 24 Jan 2014 13:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 A4zTMAHTYaXK for ; Fri, 24 Jan 2014 13:40:32 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 700A11A00C2 for ; Fri, 24 Jan 2014 13:40:32 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB25520050; Fri, 24 Jan 2014 22:40:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qOOtJfWkIU4W; Fri, 24 Jan 2014 22:40:30 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6198B20047; Fri, 24 Jan 2014 22:40:30 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E07192ACDDBE; Fri, 24 Jan 2014 22:40:27 +0100 (CET)
Date: Fri, 24 Jan 2014 22:40:27 +0100
From: Juergen Schoenwaelder 
To: Steve Waldbusser 
Message-ID: <20140124214027.GA63700@elstar.local>
Mail-Followup-To: Steve Waldbusser , mib-doctors@ietf.org
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <52E2A793.4090605@nextbeacon.com> <20140124183711.GA63456@elstar.local> <52E2B6AD.2040409@nextbeacon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52E2B6AD.2040409@nextbeacon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: mib-doctors@ietf.org
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 21:40:35 -0000

On Fri, Jan 24, 2014 at 10:53:33AM -0800, Steve Waldbusser wrote:
> On 1/24/2014 10:37 AM, Juergen Schoenwaelder wrote:
> >On Fri, Jan 24, 2014 at 09:49:07AM -0800, Steve Waldbusser wrote:
> >>I think it's great to have summary/overview tables like this up
> >>front to help people visualize the MIB.
> >>
> >>I think the 'notify' flag could be misleading. It implies that
> >>notify access could be removed and that it's a separate concept from
> >>read access.
> >The n flag allows to represent accessible-for-notify: --n
> 
> Yes, I understand that. It's just a poor way to denote it because it
> is not, in fact, independent of read access. For example r-- can
> never happen. Having the extra flag implies it can happen. I don't
> want people thinking it could possible make protocol sense to have
> an object that could be read but couldn't be included in a
> notification.
> 
> We could delete the last flag and have:
>    "not-accessible"->"---"
>    "accessible-for-notify"->"n-"
>    "read-only"->"r-"
>    "read-write"->"rw"
>    "read-create"->"rc"

>From an SMIv2 perspective, this may make sense. Note that libsmi also
implements support for SPPI and SPPI has a slightly different
PIB-ACCESS and I would have to find two flag notations for PIB-ACCESS
values as well (e.g., install "i-", notify "n-", install-notify "in",
report "-r"). Well, since nobody really seems to use SPPI (measured in
terms of the bug reports we received for the SPPI frontend), this
likely does not matter much to anyone.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From bclaise@cisco.com  Fri Jan 24 14:39:28 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71351A01E5 for ; Fri, 24 Jan 2014 14:39:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 d4ZrB1OhwNaX for ; Fri, 24 Jan 2014 14:39:25 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC6C1A01E0 for ; Fri, 24 Jan 2014 14:39:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9611; q=dns/txt; s=iport; t=1390603164; x=1391812764; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Gx+CazmbLv5V+jziIHl7tFFrCxm7VY+oLI9Ex3IWddA=; b=QGN/URC8BX43BOSIZkIGIeqYdGKPRnancHLQdZyr1ku69kVz8CZBAauk w5iws1NLPQ3fbVUVV+IcByYSWKqshNATBECJGfdU+sKOnJvvV7S73uA+g G1WeVzQ9twESFgucAGgCHW7x20BS8GIjy8CIv/9B0Ahv6Q9pgsDvikQvI s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtYIAGjq4lKQ/khN/2dsb2JhbABXA4MMOLV2hx6BCBZ0giUBAQEDAQEBASRHCgEFCQILDgIICRYPCQMCAQIBCQwwBgEMAQUCAQEXh2IIDckiFwSOeBAHCQiEJwSYJ4ZHi1eDLjs
X-IronPort-AV: E=Sophos;i="4.95,715,1384300800"; d="scan'208,217";a="3481130"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 22:39:23 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0OMdNq8029247; Fri, 24 Jan 2014 22:39:23 GMT
Message-ID: <52E2EB9A.5070406@cisco.com>
Date: Fri, 24 Jan 2014 23:39:22 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Thomas Nadeau , Juergen Schoenwaelder 
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <20140124171727.GE58781@elstar.local> <4D8B5869-C339-4CAA-8925-B0BE3D51B8F8@lucidvision.com>
In-Reply-To: <4D8B5869-C339-4CAA-8925-B0BE3D51B8F8@lucidvision.com>
Content-Type: multipart/alternative; boundary="------------040900000305030306090000"
Cc: "MIB Doctors \(E-mail\)" , Juergen Quittek 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 22:39:29 -0000

This is a multi-part message in MIME format.
--------------040900000305030306090000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This format below makes a lot of sense.
And I find Steve proposal to remove is an improvement.
Now, we would need some standard text to explain the format. We could 
put on the MIB doctors WIKI.

Regards, Benoit

> On Jan 24, 2014:12:17 PM, at 12:17 PM, Juergen Schoenwaelder  wrote:
>
>> On Fri, Jan 24, 2014 at 11:14:12AM +0000, Juergen Quittek wrote:
>>
>>> The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values:
>>>     "not-accessible"->"---"
>>>     "accessible-for-notify"->"--n"
>>>     "read-only"->"r-n"
>>>     "read-write"->"rwn"
>>>     "read-create"->"rwn" (why not "rcn"?)
>> The libsmi internally has the 'create' bit on the conceptual row and
>> not on all conceptual columns like the SMIv2 syntax has it. And as a
>> consequence, the read-create objects get marked "rwn". And since 'row'
>> and 'table' nodes do not have access bits in the tree format, the
>> 'create' bit somehow is not shown. From an SMIv2 viewpoint, this
>> surely looks surprising and "read-create"->"rcn" would likely be a
>> better solution.
>>
>> ... tak tak tak ...
>>
>> Turns out it is a two line change to make libsmi generate "rcn"
>> instead of "rwn". I can be convinced to commit this change if people
>> think this is a good idea.
>>
>> There really is no definition of the tree format (but there probably
>> should be). I also changed it a while ago the format so that it lines
>> up with the YANG tree format we use (which again was inspired by
>> smidump's tree format). Smidump's output right now looks like this:
>>
>> ---- snmpCommunityMIB(1.3.6.1.6.3.18)
>>   +---- snmpCommunityMIBObjects(1)
>>      +---- snmpCommunityTable(1)
>>         +---- snmpCommunityEntry(1) [*snmpCommunityIndex]
>>            +---- snmpCommunityIndex(1)           SnmpAdminString
>>            +-rcn snmpCommunityName(2)            OctetString
>>            +-rcn snmpCommunitySecurityName(3)    SnmpAdminString
>>            +-rcn snmpCommunityContextEngineID(4) SnmpEngineID
>>            +-rcn snmpCommunityContextName(5)     SnmpAdminString
>>            +-rcn snmpCommunityTransportTag(6)    SnmpTagValue
>>            +-rcn snmpCommunityStorageType(7)     StorageType
>>            +-rcn snmpCommunityStatus(8)          RowStatus
>>
>> Note that the object descriptor is now always at the same place. One
>> could consider also consider dropping the OID numbers - for an
>> overview, these numbers are not really important and they clutter
>> things up quite a bit. Compare to this:
>>
>> ---- snmpCommunityMIB
>>   +---- snmpCommunityMIBObjects
>>      +---- snmpCommunityTable
>>         +---- snmpCommunityEntry [*snmpCommunityIndex]
>>            +---- snmpCommunityIndex           SnmpAdminString
>>            +-rcn snmpCommunityName            OctetString
>>            +-rcn snmpCommunitySecurityName    SnmpAdminString
>>            +-rcn snmpCommunityContextEngineID SnmpEngineID
>>            +-rcn snmpCommunityContextName     SnmpAdminString
>>            +-rcn snmpCommunityTransportTag    SnmpTagValue
>>            +-rcn snmpCommunityStorageType     StorageType
>>            +-rcn snmpCommunityStatus          RowStatus
>>
>> Should we have such a discussion here?
> 	That is cool. I think its a good idea to recommend that such trees be included in the documents.
>
> 	--Tom
>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103         
>> _______________________________________________
>> MIB-DOCTORS mailing list
>> MIB-DOCTORS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>
>
>
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors


--------------040900000305030306090000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
This format below makes a lot of sense.

      And I find Steve proposal to remove is an improvement.

      Now, we would need some standard text to explain the format. We
      could put on the MIB doctors WIKI.

      

      Regards, Benoit

      

    

    

      
On Jan 24, 2014:12:17 PM, at 12:17 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:



      

        
On Fri, Jan 24, 2014 at 11:14:12AM +0000, Juergen Quittek wrote:



        

          
The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values: 
   "not-accessible"->"---"
   "accessible-for-notify"->"--n"
   "read-only"->"r-n"
   "read-write"->"rwn"
   "read-create"->"rwn" (why not "rcn"?)


        

        
The libsmi internally has the 'create' bit on the conceptual row and
not on all conceptual columns like the SMIv2 syntax has it. And as a
consequence, the read-create objects get marked "rwn". And since 'row'
and 'table' nodes do not have access bits in the tree format, the
'create' bit somehow is not shown. From an SMIv2 viewpoint, this
surely looks surprising and "read-create"->"rcn" would likely be a
better solution.

... tak tak tak ...

Turns out it is a two line change to make libsmi generate "rcn"
instead of "rwn". I can be convinced to commit this change if people
think this is a good idea.

There really is no definition of the tree format (but there probably
should be). I also changed it a while ago the format so that it lines
up with the YANG tree format we use (which again was inspired by
smidump's tree format). Smidump's output right now looks like this:

---- snmpCommunityMIB(1.3.6.1.6.3.18)
 +---- snmpCommunityMIBObjects(1)
    +---- snmpCommunityTable(1)
       +---- snmpCommunityEntry(1) [*snmpCommunityIndex]
          +---- snmpCommunityIndex(1)           SnmpAdminString
          +-rcn snmpCommunityName(2)            OctetString
          +-rcn snmpCommunitySecurityName(3)    SnmpAdminString
          +-rcn snmpCommunityContextEngineID(4) SnmpEngineID
          +-rcn snmpCommunityContextName(5)     SnmpAdminString
          +-rcn snmpCommunityTransportTag(6)    SnmpTagValue
          +-rcn snmpCommunityStorageType(7)     StorageType
          +-rcn snmpCommunityStatus(8)          RowStatus

Note that the object descriptor is now always at the same place. One
could consider also consider dropping the OID numbers - for an
overview, these numbers are not really important and they clutter
things up quite a bit. Compare to this:

---- snmpCommunityMIB
 +---- snmpCommunityMIBObjects
    +---- snmpCommunityTable
       +---- snmpCommunityEntry [*snmpCommunityIndex]
          +---- snmpCommunityIndex           SnmpAdminString
          +-rcn snmpCommunityName            OctetString
          +-rcn snmpCommunitySecurityName    SnmpAdminString
          +-rcn snmpCommunityContextEngineID SnmpEngineID
          +-rcn snmpCommunityContextName     SnmpAdminString
          +-rcn snmpCommunityTransportTag    SnmpTagValue
          +-rcn snmpCommunityStorageType     StorageType
          +-rcn snmpCommunityStatus          RowStatus

Should we have such a discussion here?


      

      
	That is cool. I think its a good idea to recommend that such trees be included in the documents.  

	--Tom



      

        
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors



      

      

      

      

      

      
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


    

    

  


--------------040900000305030306090000--

From bclaise@cisco.com  Fri Jan 24 14:53:06 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9321A01E5 for ; Fri, 24 Jan 2014 14:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 e6obyFZF8ESY for ; Fri, 24 Jan 2014 14:53:04 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98D1A01CE for ; Fri, 24 Jan 2014 14:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11050; q=dns/txt; s=iport; t=1390603982; x=1391813582; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=yLhZftdL0SlNJ+Tsa60v2rluae7lls01jua150Yh1Fg=; b=SWE74cdRtAk0KTG0yhmzv35rm2dKOo+ZgzFFrfDKmZaPGYYjo7vuBypP DDRuQOZlOQmuh8IYiVHycFZViMPuXt6gAqnPUwAf+Tfz+X8r0cXGn3g/S D4Ha6oiPE/tgb2WAh59GVH5L5ZFekC36fi6mCcoaNIzuvdnzwlhy1kGHl A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtYIAGHu4lKQ/khL/2dsb2JhbABXA4MMOLV2hx6BCBZ0giUBAQEEAQEBJEcKAQ4CCw4CCAkWDwkDAgECAQkMMAYBDAEFAgEBF4dqDckUFwSOeBAHCQiEJwSYJ4ZHi1eDLjs
X-IronPort-AV: E=Sophos;i="4.95,715,1384300800"; d="scan'208,217";a="4151034"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 24 Jan 2014 22:53:01 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0OMr1mu008528; Fri, 24 Jan 2014 22:53:01 GMT
Message-ID: <52E2EECD.1040001@cisco.com>
Date: Fri, 24 Jan 2014 23:53:01 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Thomas Nadeau , Juergen Schoenwaelder 
References: <52E24599.9020200@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E86890DF4C@DAPHNIS.office.hd> <20140124171727.GE58781@elstar.local> <4D8B5869-C339-4CAA-8925-B0BE3D51B8F8@lucidvision.com> <52E2EB9A.5070406@cisco.com>
In-Reply-To: <52E2EB9A.5070406@cisco.com>
Content-Type: multipart/alternative; boundary="------------040902040603080406030806"
Cc: "MIB Doctors \(E-mail\)" , Juergen Quittek 
Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 22:53:06 -0000

This is a multi-part message in MIME format.
--------------040902040603080406030806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 24/01/2014 23:39, Benoit Claise wrote:
> This format below makes a lot of sense.
> And I find Steve proposal to remove is an improvement.
And I find Steve's proposal to remove  "n" an improvement.
> Now, we would need some standard text to explain the format. We could 
> put on the MIB doctors WIKI.
>
> Regards, Benoit
>
>> On Jan 24, 2014:12:17 PM, at 12:17 PM, Juergen Schoenwaelder  wrote:
>>
>>> On Fri, Jan 24, 2014 at 11:14:12AM +0000, Juergen Quittek wrote:
>>>
>>>> The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values:
>>>>     "not-accessible"->"---"
>>>>     "accessible-for-notify"->"--n"
>>>>     "read-only"->"r-n"
>>>>     "read-write"->"rwn"
>>>>     "read-create"->"rwn" (why not "rcn"?)
>>> The libsmi internally has the 'create' bit on the conceptual row and
>>> not on all conceptual columns like the SMIv2 syntax has it. And as a
>>> consequence, the read-create objects get marked "rwn". And since 'row'
>>> and 'table' nodes do not have access bits in the tree format, the
>>> 'create' bit somehow is not shown. From an SMIv2 viewpoint, this
>>> surely looks surprising and "read-create"->"rcn" would likely be a
>>> better solution.
>>>
>>> ... tak tak tak ...
>>>
>>> Turns out it is a two line change to make libsmi generate "rcn"
>>> instead of "rwn". I can be convinced to commit this change if people
>>> think this is a good idea.
>>>
>>> There really is no definition of the tree format (but there probably
>>> should be). I also changed it a while ago the format so that it lines
>>> up with the YANG tree format we use (which again was inspired by
>>> smidump's tree format). Smidump's output right now looks like this:
>>>
>>> ---- snmpCommunityMIB(1.3.6.1.6.3.18)
>>>   +---- snmpCommunityMIBObjects(1)
>>>      +---- snmpCommunityTable(1)
>>>         +---- snmpCommunityEntry(1) [*snmpCommunityIndex]
>>>            +---- snmpCommunityIndex(1)           SnmpAdminString
>>>            +-rcn snmpCommunityName(2)            OctetString
>>>            +-rcn snmpCommunitySecurityName(3)    SnmpAdminString
>>>            +-rcn snmpCommunityContextEngineID(4) SnmpEngineID
>>>            +-rcn snmpCommunityContextName(5)     SnmpAdminString
>>>            +-rcn snmpCommunityTransportTag(6)    SnmpTagValue
>>>            +-rcn snmpCommunityStorageType(7)     StorageType
>>>            +-rcn snmpCommunityStatus(8)          RowStatus
>>>
>>> Note that the object descriptor is now always at the same place. One
>>> could consider also consider dropping the OID numbers - for an
>>> overview, these numbers are not really important and they clutter
>>> things up quite a bit. Compare to this:
>>>
>>> ---- snmpCommunityMIB
>>>   +---- snmpCommunityMIBObjects
>>>      +---- snmpCommunityTable
>>>         +---- snmpCommunityEntry [*snmpCommunityIndex]
>>>            +---- snmpCommunityIndex           SnmpAdminString
>>>            +-rcn snmpCommunityName            OctetString
>>>            +-rcn snmpCommunitySecurityName    SnmpAdminString
>>>            +-rcn snmpCommunityContextEngineID SnmpEngineID
>>>            +-rcn snmpCommunityContextName     SnmpAdminString
>>>            +-rcn snmpCommunityTransportTag    SnmpTagValue
>>>            +-rcn snmpCommunityStorageType     StorageType
>>>            +-rcn snmpCommunityStatus          RowStatus
>>>
>>> Should we have such a discussion here?
>> 	That is cool. I think its a good idea to recommend that such trees be included in the documents.
>>
>> 	--Tom
>>
>>> /js
>>>
>>> -- 
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>>> Fax:   +49 421 200 3103
>>> _______________________________________________
>>> MIB-DOCTORS mailing list
>>> MIB-DOCTORS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>>
>>
>>
>> _______________________________________________
>> MIB-DOCTORS mailing list
>> MIB-DOCTORS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mib-doctors
>
>
>
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors


--------------040902040603080406030806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 24/01/2014 23:39, Benoit Claise
      wrote:

    

    

      
      
This format below makes a lot of
        sense.

        And I find Steve proposal to remove is an improvement.

      

    

    And I find Steve's proposal to remove  "n" an improvement.
    

      
 Now, we would need some standard
        text to explain the format. We could put on the MIB doctors
        WIKI.

        

        Regards, Benoit

        

      

      

        
On Jan 24, 2014:12:17 PM, at 12:17 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:



        

          
On Fri, Jan 24, 2014 at 11:14:12AM +0000, Juergen Quittek wrote:



          

            
The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values: 
   "not-accessible"->"---"
   "accessible-for-notify"->"--n"
   "read-only"->"r-n"
   "read-write"->"rwn"
   "read-create"->"rwn" (why not "rcn"?)


          

          
The libsmi internally has the 'create' bit on the conceptual row and
not on all conceptual columns like the SMIv2 syntax has it. And as a
consequence, the read-create objects get marked "rwn". And since 'row'
and 'table' nodes do not have access bits in the tree format, the
'create' bit somehow is not shown. From an SMIv2 viewpoint, this
surely looks surprising and "read-create"->"rcn" would likely be a
better solution.

... tak tak tak ...

Turns out it is a two line change to make libsmi generate "rcn"
instead of "rwn". I can be convinced to commit this change if people
think this is a good idea.

There really is no definition of the tree format (but there probably
should be). I also changed it a while ago the format so that it lines
up with the YANG tree format we use (which again was inspired by
smidump's tree format). Smidump's output right now looks like this:

---- snmpCommunityMIB(1.3.6.1.6.3.18)
 +---- snmpCommunityMIBObjects(1)
    +---- snmpCommunityTable(1)
       +---- snmpCommunityEntry(1) [*snmpCommunityIndex]
          +---- snmpCommunityIndex(1)           SnmpAdminString
          +-rcn snmpCommunityName(2)            OctetString
          +-rcn snmpCommunitySecurityName(3)    SnmpAdminString
          +-rcn snmpCommunityContextEngineID(4) SnmpEngineID
          +-rcn snmpCommunityContextName(5)     SnmpAdminString
          +-rcn snmpCommunityTransportTag(6)    SnmpTagValue
          +-rcn snmpCommunityStorageType(7)     StorageType
          +-rcn snmpCommunityStatus(8)          RowStatus

Note that the object descriptor is now always at the same place. One
could consider also consider dropping the OID numbers - for an
overview, these numbers are not really important and they clutter
things up quite a bit. Compare to this:

---- snmpCommunityMIB
 +---- snmpCommunityMIBObjects
    +---- snmpCommunityTable
       +---- snmpCommunityEntry [*snmpCommunityIndex]
          +---- snmpCommunityIndex           SnmpAdminString
          +-rcn snmpCommunityName            OctetString
          +-rcn snmpCommunitySecurityName    SnmpAdminString
          +-rcn snmpCommunityContextEngineID SnmpEngineID
          +-rcn snmpCommunityContextName     SnmpAdminString
          +-rcn snmpCommunityTransportTag    SnmpTagValue
          +-rcn snmpCommunityStorageType     StorageType
          +-rcn snmpCommunityStatus          RowStatus

Should we have such a discussion here?


        

        
	That is cool. I think its a good idea to recommend that such trees be included in the documents.  

	--Tom



        

          
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors



        

        

        

        

        
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


      

      

      

      

      

      
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


    

    

  


--------------040902040603080406030806--

From bertietf@bwijnen.net  Mon Jan 27 22:56:58 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CB61A024F for ; Mon, 27 Jan 2014 22:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 GQvldwpOw6uy for ; Mon, 27 Jan 2014 22:56:56 -0800 (PST)
Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 8A04F1A022F for ; Mon, 27 Jan 2014 22:56:56 -0800 (PST)
Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W82b9-0000ee-7B; Tue, 28 Jan 2014 07:56:49 +0100
Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W82b8-00057r-Pr; Tue, 28 Jan 2014 07:56:39 +0100
Message-ID: <52E754A4.3080702@bwijnen.net>
Date: Tue, 28 Jan 2014 07:56:36 +0100
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Nobo Akiya (nobo)" ,  "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" ,  "ops-ads@tools.ietf.org" , "mib-doctors@ietf.org" 
References: <066d01cf0416$bccb85c0$36629140$@olddog.co.uk> <52D57335.40205@cisco.com> <52D576E1.9060600@bwijnen.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c1917011e2022b88830bb68ce88b3cff
Cc: "Zafar Ali \(zali\)" , "bfd-chairs@tools.ietf.org" 
Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 06:56:58 -0000

my appologies,

I did not get to it last week, and this week I am in an all week
ISOC Board meeting. Will try to work on it next week.

Bert

On 14/01/14 19:42, Nobo Akiya (nobo) wrote:
> Hi,
>
> Thank you Bert. There were number of comments provided from Adrian. It'll be beneficial to address those before MIB doctor pass through. Tom/Zafar, can you notify Bert when pending comments have been addressed?
>
> Thanks,
> Nobo
>
>> -----Original Message-----
>> From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
>> Sent: Tuesday, January 14, 2014 12:42 PM
>> To: Benoit Claise (bclaise); adrian@olddog.co.uk; ops-ads@tools.ietf.org;
>> mib-doctors@ietf.org
>> Cc: bfd-chairs@tools.ietf.org
>> Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe
>>
>> I can do these in the next week or so.
>>
>> Bert
>>
>> On 14/01/14 18:26, Benoit Claise wrote:
>>> Dear MIB doctors,
>>>
>>> Who would like to volunteer?
>>> A simple comparison between the MIB doctors list
>>> (http://www.ietf.org/iesg/directorate/mib-doctors.html) and the latest
>>> assignments
>>> (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history)
>> would guide me in kindly requesting the next volunteers.
>>> However, it's always better if you volunteer yourself :-)
>>>
>>> Regards, Benoit
>>>
>>>> Hi,
>>>>
>>>> Heads up that two documents are in the pipe.
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/
>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/
>>>>
>>>> I shall be reviewing them as AD in the next couple of days and then
>>>> expect to issue IETF last call.
>>>>
>>>> Thanks for the work.
>>>>
>>>> Adrian
>>>>
>>>> _______________________________________________
>>>> MIB-DOCTORS mailing list
>>>> MIB-DOCTORS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>>>
>>>
>>> _______________________________________________
>>> MIB-DOCTORS mailing list
>>> MIB-DOCTORS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>>
>

From tnadeau@lucidvision.com  Tue Jan 28 07:09:27 2014
Return-Path: 
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747DA1A0432 for ; Tue, 28 Jan 2014 07:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 O5L6TFGLtD02 for ; Tue, 28 Jan 2014 07:09:25 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 035881A0433 for ; Tue, 28 Jan 2014 07:09:23 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5988C26CDC1B; Tue, 28 Jan 2014 10:09:20 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FF32D4D6-964B-4221-8BC2-B85909325242"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <52E754A4.3080702@bwijnen.net>
Date: Tue, 28 Jan 2014 10:09:20 -0500
Message-Id: <238BAE0D-B72C-44CD-B6FB-E69D6F1A51B5@lucidvision.com>
References: <066d01cf0416$bccb85c0$36629140$@olddog.co.uk> <52D57335.40205@cisco.com> <52D576E1.9060600@bwijnen.net>  <52E754A4.3080702@bwijnen.net>
To: "Bert Wijnen (IETF)" 
X-Mailer: Apple Mail (2.1827)
Cc: "mib-doctors@ietf.org" , "ops-ads@tools.ietf.org" , "Nobo Akiya \(nobo\)" , "bfd-chairs@tools.ietf.org" , Farrel Adrian , "Zafar Ali \(zali\)" 
Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 15:09:27 -0000

--Apple-Mail=_FF32D4D6-964B-4221-8BC2-B85909325242
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


	Looking at the edits/issues is on my plate as soon as I wrap up =
a few things, so yes I will alert Bert with responses.=20

	--Tom

> my appologies,
>=20
> I did not get to it last week, and this week I am in an all week
> ISOC Board meeting. Will try to work on it next week.
>=20
> Bert
>=20
> On 14/01/14 19:42, Nobo Akiya (nobo) wrote:
>> Hi,
>>=20
>> Thank you Bert. There were number of comments provided from Adrian. =
It'll be beneficial to address those before MIB doctor pass through. =
Tom/Zafar, can you notify Bert when pending comments have been =
addressed?
>>=20
>> Thanks,
>> Nobo
>>=20
>>> -----Original Message-----
>>> From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
>>> Sent: Tuesday, January 14, 2014 12:42 PM
>>> To: Benoit Claise (bclaise); adrian@olddog.co.uk; =
ops-ads@tools.ietf.org;
>>> mib-doctors@ietf.org
>>> Cc: bfd-chairs@tools.ietf.org
>>> Subject: Re: [MIB-DOCTORS] Heads up MIB documents in the pipe
>>>=20
>>> I can do these in the next week or so.
>>>=20
>>> Bert
>>>=20
>>> On 14/01/14 18:26, Benoit Claise wrote:
>>>> Dear MIB doctors,
>>>>=20
>>>> Who would like to volunteer?
>>>> A simple comparison between the MIB doctors list
>>>> (http://www.ietf.org/iesg/directorate/mib-doctors.html) and the =
latest
>>>> assignments
>>>> =
(http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history)=

>>> would guide me in kindly requesting the next volunteers.
>>>> However, it's always better if you volunteer yourself :-)
>>>>=20
>>>> Regards, Benoit
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> Heads up that two documents are in the pipe.
>>>>>=20
>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/
>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/
>>>>>=20
>>>>> I shall be reviewing them as AD in the next couple of days and =
then
>>>>> expect to issue IETF last call.
>>>>>=20
>>>>> Thanks for the work.
>>>>>=20
>>>>> Adrian
>>>>>=20
>>>>> _______________________________________________
>>>>> MIB-DOCTORS mailing list
>>>>> MIB-DOCTORS@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> MIB-DOCTORS mailing list
>>>> MIB-DOCTORS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>>>=20
>>=20
>=20


--Apple-Mail=_FF32D4D6-964B-4221-8BC2-B85909325242
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS58ggAAoJEPcO+I7eiUJZpl8P/2fPisewxmuEc4YrbdKlUlyh
9OhQZuQNSoisHEbC+B9nOb6B31gL2QCwpWJle0nhxVx46C54uBBBjasAm+dcnZI0
BlN5hDxYCGIp/+JEdSe8pGdp0nGKZjv/IQQNCRbuzC2dhgRK4SCChIN2cwlZdZwi
GYkWvX0N330G2YPtex1zaZsv3tko8i+ZJV3G5O5VuWI6fJgJw8u5KUAe1trOF513
4FOby/yEOzzenpVUEwJVgPp4k+qcYI8FdFFwQRFblBUETtZ6/bD3ohB5guHs7Bui
2QIW9AAcobAlQ3OfeJkfnevVxSV9Xd/BC1NxvEzocn3M5P+6uMKTKDoVcyFSOrjB
JbLAXqFpLccVXsCHpxxK4y4aoSpPjOerohQ1yvCJOqdn4ebstS07SSkcgOoKfXW+
8JpVTI0KUjnYJVZGMkzyROw5zuymZ1Qp+oE86/mPOjl2YE+Hir7ibSAM6VYmpNQd
pFphwe4YmIncAK3Lsb0iqkN/rHXWfBaGuXT39EHz4xlYxks0L0t62EhLKbnK369O
FwWqBKweoZKwiwfVeDk/NRRFcyw0T+kIXmPnD6q9tCYZBPh+P+vGmrDGMx0ur5NQ
Vu4bk0A1s6/9ULjAi83Z2gGsUv9GiPzBjsNYCVn2QWFUoYHfQPVF3cBJwU9P3WYz
21RpUCZ1EZnVjg560nw4
=sh1W
-----END PGP SIGNATURE-----

--Apple-Mail=_FF32D4D6-964B-4221-8BC2-B85909325242--