Re: Gen-ART review of draft-ietf-bfd-mib-17

Jeffrey Haas <> Thu, 17 April 2014 22:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A4F6F1A00D1; Thu, 17 Apr 2014 15:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uxxf6ice03wp; Thu, 17 Apr 2014 15:18:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6449C1A0173; Thu, 17 Apr 2014 15:18:54 -0700 (PDT)
Received: by (Postfix, from userid 1001) id CB696C2A3; Thu, 17 Apr 2014 18:18:50 -0400 (EDT)
Date: Thu, 17 Apr 2014 18:18:50 -0400
From: Jeffrey Haas <>
To: "Sam K. Aldrin" <>
Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
Message-ID: <20140417221850.GD29430@pfrc>
References: <> <051b01cf5a87$b92a84d0$2b7f8e70$> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc:, "'Black, David'" <>,,,, 'General Area Review Team' <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Apr 2014 22:18:55 -0000


On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote:
> %sam - If this MIB allows write access, do you/WG anticipate, any extension to the MIB should also provide write-access as well? For example: augments this base MIB to support MPLS. It adds more confusion than solving the issue as base MIB supports write-access, but augmented/ MIB extension doesn't. 
> As the BFD MIB authors were not supportive of write-access objects in the MIBs, why to have them in the first place? 

As noted in earlier mailing list chatter, there is some support for write
access in existing implementations.  Given the lack of significant detail
when pressed for the name of such an implementation, I'm suspecting smaller
vendor or internal implementation.  That's still sufficient to leave write

Given that one of the original contexts of asking if we could remove write
was whether IETF was being asked to provide such a thing for MPLS-TP with
related impact on your extension MIB and the answer was "no", that shouldn't
be the main criteria.  

My suspicion is that if we were to ship the base MIB with writeable objects,
we may be forced to consider similar things for the extension MIB(s).

-- Jeff