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

["Nobo Akiya (nobo)" <[e-mail]>]

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.

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