Thanks, Nobo. Much appreciated. -sam On Apr 17, 2014, at 7:17 PM, Nobo Akiya (nobo) <nobo@xxxxxxxxx> wrote: > Hi Sam, > >> -----Original Message----- >> From: Sam K. Aldrin [mailto:aldrin.ietf@xxxxxxxxx] >> Sent: Thursday, April 17, 2014 9:24 PM >> To: Nobo Akiya (nobo) >> Cc: Jeffrey Haas; ietf@xxxxxxxx; 'Black, David'; adrian@xxxxxxxxxxxx; rtg- >> bfd@xxxxxxxx; 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. > > -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 >>> >