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

[Thomas Nadeau <[e-mail]>]

On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise <[e-mail]> wrote:

> 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.

	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.

	--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:
>>>>> 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
>> .
>> 
> 
>