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

"Sam K. Aldrin" <> Fri, 18 April 2014 01:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B6CD1A018F; Thu, 17 Apr 2014 18:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NdC8r-4JTAZc; Thu, 17 Apr 2014 18:24:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::233]) by (Postfix) with ESMTP id 7B96F1A0057; Thu, 17 Apr 2014 18:24:28 -0700 (PDT)
Received: by with SMTP id kq14so958280pab.38 for <multiple recipients>; Thu, 17 Apr 2014 18:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=35aHL2qacWZN28WEqFB9sF9D1eRAX7ZaqHAhqbfSSZ8=; b=LmBGZd1Ai2g4tjRlc47UHbYKa5zPK4ykWzA+m/68o1aeQEBgmxPhejTD1FxPy451b+ nuFWtJUtwVbRE959WgzC0wghGxfi4cqFSTUVD839yocc31w1S6Ejkmwadz0pxmmMBzw/ b/xrwLyS7B2M9/7JWFk9i5jN/HbC6F6Qdsf5XKFlcW3XwZC4ewHtckiRuXjpztrvYJkq LEmJyG0YxHVh4pvEFEG3gwtgey9cg74VmNoaoffPoe4QCiQS46MeiX0wxNjYtWDr9Jqg P0vCk0QQB6uI8BTDEvH9tAV1aBROO3m6yVZAI+u/5Xa6KbgGX6I1TTOsdv0kriYqYSJU YIFw==
X-Received: by with SMTP id qw7mr19092420pbb.68.1397784264847; Thu, 17 Apr 2014 18:24:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id pv4sm56277102pbb.55.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 18:24:24 -0700 (PDT)
Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: "Sam K. Aldrin" <>
In-Reply-To: <>
Date: Thu, 17 Apr 2014 18:24:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <051b01cf5a87$b92a84d0$2b7f8e70$> <> <20140417221850.GD29430@pfrc> <> <>
To: "Nobo Akiya (nobo)" <>
X-Mailer: Apple Mail (2.1283)
Cc: "" <>, "'Black, David'" <>, "" <>, "" <>, "Zafar Ali \(zali\)" <>, '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: Fri, 18 Apr 2014 01:24:30 -0000

Hi Nobo,
[sorry for the top post]

Yes, this is an old MIB and was in existence for a long time. 
My only concern is with the new extension MIB's. If the base MIB (this MIB) has write access, future extension MIB's may be forced to support write-access. And that is the painful part, where community at large has not shown interest in developing write-access MIB's at IETF, lest implementation. 

I want to re-iterate again, I am not objecting or proposing an alternative option. Just wanted to get clarification, so that, we don't have to burn cycles and do the exercise again, when we have to review these new extension MIB's.


On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote:

> Hi Sam,
>>> 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 available.
>>> 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.
>> No. The context of my question is not related to MPLS-TP as such, but write-
>> access support in general.
>> I should have added 'clarification' in my earlier email.
>>> 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).
>> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE and
>> BFD-MIB respectively,  with write-access. Had to do write-access because of
>> the reason you've mentioned above, which is base MIB. It would be painful
>> to publish/support write-access MIB's when there is no clear interest. Hence
>> my clarification question.
> This mentions three vendors wanting to implement MIB as writable.
> And one more vendor voicing for writable.
> I agree that defining & wording writable MIB is much more painful than all read-only MIB. But above thread indicates the desire by multiple vendors to implement writable BFD MIB. Therefore it does seem that there are interests, and going forward with write-access will benefit the community. And with *ReadOnlyCompliance defined, BFD MIB can also accommodate those implementing them as just read-only.
> -Nobo
>> -sam
>>> -- Jeff