IETF Logo Mail Archive

RE: Adoption of draft-vkst-bfd-mpls-mib

Muly Ilan <muly_i@rad.com> Wed, 27 June 2012 14:49 UTC

Return-Path: <muly_i@rad.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F94121F85E6 for <rtg-bfd@ietfa.amsl.com>; Wed, 27 Jun 2012 07:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level:
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvB1g4V1N9Qm for <rtg-bfd@ietfa.amsl.com>; Wed, 27 Jun 2012 07:49:29 -0700 (PDT)
Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1721F85E5 for <rtg-bfd@ietf.org>; Wed, 27 Jun 2012 07:49:26 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 27 Jun 2012 17:29:56 +0300
Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 17:49:23 +0300
From: Muly Ilan <muly_i@rad.com>
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Adoption of draft-vkst-bfd-mpls-mib
Thread-Topic: Adoption of draft-vkst-bfd-mpls-mib
Thread-Index: AQHNVHEh49sZMUraLkecA5jIAlQv1pcOPboQ
Date: Wed, 27 Jun 2012 14:49:23 +0000
Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87042C6149@EXRAD5.ad.rad.co.il>
References: <20120601151238.GV4067@pfrc> <FE60A4E52763E84B935532D7D9294FF1355478AEFB@EUSAACMS0715.eamcs.ericsson.se> <C1F7AB81-3232-4A43-A6BC-0FD3879D6874@lucidvision.com> <F99D3C25-4885-41B3-BC2F-CD2B5EA037FE@gmail.com> <20120627142822.GE18361@pfrc>
In-Reply-To: <20120627142822.GE18361@pfrc>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.17.170.136]
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A0B0209.4FEB1D74.0068,ss=1,pt=DBB_65836,fgs=0
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2012 14:49:30 -0000

Hi,

We, at RAD, plan to support the write-access to this BFD extension MIB.

Regards,


Muly Ilan
Senior System Architect, R&D
T: +972-3-765-7035 | M: +972-54-470-1004 | F: +972-3-644-0930  | muly_i@rad.com 
RAD Data Communications Ltd. 24, Raoul Wallenberg St. Tel-Aviv 69719, Israel  | www.rad.com



-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Wednesday, June 27, 2012 5:28 PM
To: Sam Aldrin
Cc: rtg-bfd@ietf.org
Subject: Re: Adoption of draft-vkst-bfd-mpls-mib

Sam,

On Tue, Jun 05, 2012 at 05:35:37PM -0700, Sam Aldrin wrote:
> We were asked specifically by the WG chairs, in the Paris WG session, to add read write option to the MIB. AD and MPLS WG chair also provided their comments and felt BFD MIB extension to support TP should have write support.

This was under the presumption that we needed to provide this as part of our MPLS-TP agreement with ITU.  After consulting with the MPLS chairs (or at least, per Loa's answer) and our ADs, this doesn't appear to be the case. 

So, as a motivating factor, we don't need it.

> There are at least three vendors who are requesting write support as well.

*That* is far more interesting.  Per other discussions off-list, I was considering polling the WG to see if we should consider removing the write profile for the MIBs.

Would those three vendors be willing to go on record stating that they want write-access to the MIB?  This wouldn't be a formal statement of "we'll support this in X version of our software", just "we want the option to be able to do SNMP SET in this MIB."  Having some sort of public statement for this would help an upcoming OPS open-area meeting at the upcoming IETF in Vancouver with regard to this general topic.

If the vendors aren't willing to publicly state this but are willing to privately do so, that would also be helpful.

> To the original comment that there is no requirement for write support for MIB, my answer is, there is no requirement to have just read only either. If there is consensus that, write option shouldnt exist in MIBs, it should be stated so. Otherwise, the confusion will persist every time.

In general, a read-only profile is desirable because there exists a set of vendors who have no intention to provide SNMP SET access to their MIB implementations.  Without a supporting conformance statement, those vendors are not conformant.  Obviously the protocol works just fine read-only, but it upsets the people who track such things in spreadsheets. :-)

-- Jeff

v2.23.0 | Report a Bug | By Email