The -18 version of this draft responds to all of the comments in the Gen-ART review of -17, including the request for coordination w/the OPS area, although I wasn't exactly expecting that to occur on the main IETF list. The -18 version is ready with one small nit - The following text has been added to the introduction: This memo does not define a compliance requirement for a system that only implements BFD version 0. This is a reflection of a considered and deliberate decision by the BFD WG. An explanation of the rationale for that decision would help - I suggest adding the following text and a suitable reference to the end of the text above: because the BFD version 0 protocol may deadlock and hence SHOULD NOT be used, as explained further in [RFCxxxx]. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, April 16, 2014 7:31 PM > To: tnadeau@xxxxxxxxxxxxxxx; zali@xxxxxxxxx; nobo@xxxxxxxxx; 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). > > 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 > ----------------------------------------------------