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

Benoit Claise <> Fri, 18 April 2014 12:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C05931A01F6; Fri, 18 Apr 2014 05:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Status: No, score=-9.773 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.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bZXkzubpP6WY; Fri, 18 Apr 2014 05:06:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B6B91A0208; Fri, 18 Apr 2014 05:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5179; q=dns/txt; s=iport; t=1397822806; x=1399032406; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WMcgKt5iEVVOziy2T0Qu/vnY+NvLYvE0yk6xHct/scg=; b=DvcK+m+JKy2TbUZducgPC4glzQRmHCKUUID1pFs0yI7Vth6DUiRgvQaV D1YhdSRFveJARXZP7R5nd/sRxIOE3R9Dlxydz2qsozi7sGMPdBwyvVFZC grN2V16vzmQHTTDgjCDLRxWj9/YKIQCZ9qd31wU+eF1S7/GLtnjM3fTCv 0=;
X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="14946174"
Received: from (HELO ([]) by with ESMTP; 18 Apr 2014 12:06:45 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s3IC6i88025687; Fri, 18 Apr 2014 12:06:44 GMT
Message-ID: <>
Date: Fri, 18 Apr 2014 14:06:44 +0200
From: Benoit Claise <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Thomas Nadeau <>
Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
References: <> <051b01cf5a87$b92a84d0$2b7f8e70$> <> <20140417221850.GD29430@pfrc> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, "Black, David" <>, Farrel Adrian <>, "" <>, "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 12:06:55 -0000

On 18/04/2014 13:51, Thomas Nadeau wrote:
> On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise <> wrote:
>> On 18/04/2014 04:17, Nobo Akiya (nobo) wrote:
>>> Hi Sam,
>>>> -----Original Message-----
>>>> From: Sam K. Aldrin []
>>>> Sent: Thursday, April 17, 2014 9:24 PM
>>>> To: Nobo Akiya (nobo)
>>>> Cc: Jeffrey Haas;; 'Black, David';; rtg-
>>>>; Zafar Ali (zali); 'General Area Review Team'
>>>> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
>>>> 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.
>>> That's a good point, it would be good to have this clarified for future work.
>>> IMO:
>>> For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if gets included in the charter) should look into NETCONF/YANG (i.e. not extension to the BFD base MIB).
>>> For currently chartered BFD tasks, the BFD WG should continue with writable MIB. Large part of that is the BFD base & MPLS MIBs which [painful] writable effort is mostly done already.
>> This is in essence what says.
>> Regards, Benoit.
> 	Yes, this is why we left the writable stuff in - and why I recently spent about 4 hours doing Adrian's edits around support of such things.  Lets please put the discussion around read-write to bed for these two modules as they clearly were well under way and complete by the time the statement came out.
No disagreement.

Regards, B.
> 	--Tom
>>> -Nobo
>>>> -sam
>>>> 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
>>> .