Hi David, Thank you for thorough review of this document. Please see replies in-line. > -----Original Message----- > From: Black, David [mailto:david.black@xxxxxxx] > Sent: Wednesday, April 16, 2014 7:31 PM > To: tnadeau@xxxxxxxxxxxxxxx; Zafar Ali (zali); Nobo Akiya (nobo); General > Area Review Team (gen-art@xxxxxxxx) > Cc: rtg-bfd@xxxxxxxx; ietf@xxxxxxxx; Black, David > Subject: Gen-ART review of draft-ietf-bfd-mib-17 > > I am the assigned Gen-ART reviewer for this draft. For background on Gen- > ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-bfd-mib-17 > Reviewer: David L. Black > Review Date: April 16, 2014 > IETF LC End Date: April 28, 2014 > > Summary: This draft is on the right track, but has open issues > described in the review. > > This draft is a MIB module for the BFD protocol, which is an important low- > level routing protocol. The draft is reasonable for a MIB draft; one needs to > go read the protocol documents to understand how the protocol works, and > significant portions of the text are derived from the usual MIB "boilerplate" > as one would expect. The "Brief Description of MIB Objects" is indeed brief, > but reasonable. The shepherd writeup indicates that there are multiple > implementations. > > Major issues: > > This MIB contains many writable objects, so the authors should take note of > the IESG statement on writable MIB modules: > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > I did not see this mentioned in the shepherd writeup. If the OPS Area has > not been consulted, I strongly suggest doing so during IETF Last Call, e.g., > starting with Benoit Claise (AD). I remember seeing the statement from IESG, which I agree is a good direction for new charter items. [This] BFD MIB, on the other hand, is almost 10 years old, with several implementations already around. I highly suspect the WG will not want to see *change of direction* at this point. With that said, let me take this up with the AD and the Shepherd. > > Minor issues: > > The security considerations section includes considerations for > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus, > but omits the corresponding considerations for bfdAdminStatus and > bfdSessNotificationsEnable. Both of the latter objects are global, so > significant damage can be inflicted via these objects with a small number of > unauthorized modifications, so they need to be included in the first list of > sensitive objects. Good point. I will add bfdAdminStatus and bfdOperStatus in the security considerations section. > > I suggest that the authors recheck the entire MIB to ensure that every object > or table that should be included in the security considerations section is > appropriately included. I've gone through them. There are set of objects which really should not be modified once a session is functioning. I've added this in the security considerations section. o Some management objects define the BFD session whilst other management objects define the parameter of the BFD session. It is particularly important to control the support for SET access to those management objects that define the BFD session, as changes to them can be disruptive. Implementation SHOULD NOT allow changes to following management objects when bfdSessState is up(4): * bfdSessVersionNumber * bfdSessType * bfdSessDestinationUdpPort * bfdSessMultipointFlag * bfdSessInterface * bfdSessSrcAddrType * bfdSessSrcAddr * bfdSessDstAddrType * bfdSessDstAddr > > Also, as a General Variable, would bfdSessNotificationsEnable be better > named bfdNotificationsEnable, as it's not in the BFD Session Table? That's true. Renamed as suggested. > > I did not see a compliance requirement for a system that only implements > BFD protocol version 0. That absence should at least be mentioned > somewhere. For example, if this reflects a considered and deliberate > decision by the WG, that should be mentioned in the introduction. Good point. If I remember correctly, BFD version 0 had a problem in the state machine that can cause the two ends to fall into a deadlock. It would be, therefore, very bad for anybody to have BFD version 0 deployed out there, and asking for any MIB compliance requirement for such. Consensus on absence of compliance requirement for BFD version 0 was never polled in the WG, but I can say that there shouldn't be any desire for that. I will add a short statement on lack of BFD version 0 compliance requirement in the introduction section, as you suggested. > > Nits/editorial comments: > > In the security considerations for authentication-related objects: > > OLD > In order for these sensitive information > from being improperly accessed, implementers MAY wish to disallow > access to these objects. > NEW > In order to prevent this sensitive information > from being improperly accessed, implementers MAY disallow > access to these objects. Thanks for the text. Updated in local copy. > > idnits 2.13.01 found a truly minor nit that should be corrected when the > draft is next revised: > > == Outdated reference: A later version (-05) exists of > draft-ietf-bfd-tc-mib-04 Agree, non-issue. > > it also generated a warning that probably does not reflect an actual > problem: > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If you > have contacted all the original authors and they are all willing to grant > the BCP78 rights to the IETF Trust, then this is fine, and you can ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) Agree, non-issue. Thanks again! -Nobo > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > ----------------------------------------------------