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