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

[Benoit Claise <[e-mail]>]

On 18/04/2014 04:17, Nobo Akiya (nobo) wrote:
> Hi Sam,
>
>> -----Original Message-----
>> From: Sam K. Aldrin [mailto:[e-mail]]
>> Sent: Thursday, April 17, 2014 9:24 PM
>> To: Nobo Akiya (nobo)
>> Cc: Jeffrey Haas; [e-mail]; 'Black, David'; [e-mail]; rtg-
>> [e-mail]; 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 
https://www.ietf.org/iesg/statement/writable-mib-module.html says.

Regards, Benoit.
>
> -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:
>>>> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ 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.
>>>
>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html
>>>
>>> And one more vendor voicing for writable.
>>>
>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html
>>>
>>> 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
> .
>