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). 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. 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. Also, as a General Variable, would bfdSessNotificationsEnable be better named bfdNotificationsEnable, as it's not in the BFD Session Table? 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. 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. 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 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.) 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 ----------------------------------------------------